Reverse proxy w IIS

  • Article

Idea reverse proxy nie jest specjalnie skomplikowana. Mamy serwer, do którego trafiaja zapytania ze swiata, ten serwer odpytuje jakis inny serwer http (serwer aplikacyjny) a otrzymana odpowiedz przekazuje klientowi tak, jakby wygenerowal ja sam. Po co tak kombinowac? Powodów moze byc wiele, wsród których wymienic warto chociazby:

  • Serwery aplikacyjne nie musza byc "wystawione" do swiata a reverse proxy zadba o odfiltrowanie niepozadanych zapytan. Sam IIS ma sporo ciekawych filtrów (wlacznie z ModSecurity) a dalej przekazane zostana tylko "grzeczne" zapytania.
  • Stosunkowo prosty reverse proxy moze znajdowac sie u providera wyposazonego w lacza o poteznej przepustowosci, dzieki czemu to na nim skupia sie ataki DDoS. Wystarczy to polaczyc z Dynamic IP Filtering (wbudowanym w ISS8, dodatkowym w starszych wersjach) i juz mamy calkiem ladne zabezpieczenie a serwery aplikacyjne zostaja u nas w firmie.
  • Informacja z wielu serwerów aplikacyjnych moze byc przedstawiana klientowi tak, jakby znajdowala sie na jednym – adres dla klienta pozostaje ten sam i jest adresem reverse proxy.
  • Wystarczy jeden zewnetrzny adres IP i adres URL do pokazania swiatu zawartosci dowolnej ilosci serwerów aplikacyjnych. Równiez takich, które dzialaja na jednym serwerze, ale na róznych portach TCP.
  • Za reverse proxy mozna "schowac" szczególy budowy rozwiazania. Adresy wystawione do swiata moga byc ladne i przyjazne, podczas gdy serwer aplikacyjny w adresie URL wymaga podania danych, których nie chcemy pokazywac publicznie.
  • Reverse proxy pokazuje klientom swoja wersje, oprogramowanie, naglówki i inne potencjalnie wrazliwe szczególy.
  • Reverse proxy moze (nie musi) buforowac informacje otrzymane od serwerów aplikacyjnych, dzieki czemu zmniejsza ich obciazenie.
  • Na reverse proxy mozna przerzucic cala robote zwiazana z obsluga SSL.

Podobnych powodów moznaby wymieniac wiele.

Jezeli ktokolwiek chce to zrobic w swoim srodowisku, moze przebierac w rozwiazaniach. Od mniej lub bardziej zaawansowanych rozwiazan Open Source az po specjalizowane urzadzenia. Tymczasem, zupelnie dobrze reverse proxy mozna zbudowac w oparciu o IIS. Potrzebne beda:

Warto wiedziec, ze wymienione powyzej moduly mozna instalowac przez mechanizm Web Platform Installer (WebPI) – dzieki temu instalacja jest znaczaco prostsza i przebiega bezproblemowo.

Po instalacji, na poziomie serwera nalezy wlaczyc funkcjonalnosc reverse proxy, opcjonalnie ustawiajac parametry buforowania.

iisrev01

 

Na poziomie site’ów i folderów wirtualnych, w ramach modulu URL Rewrite trzeba skonfigurowac inbound rules, sluzace do tlumaczenia zapytan przychodzacych ze swiata na zapytania do serwerów aplikacyjnych.

iisrev02

Oczywiscie, reguly tlumaczenia zapytan sa dosc elastyczne (match, wildcard i regexp) i pozwalaja na realizacje calkiem zaawansowanych scenariuszy.

I gotowe! Warto pamietac o jeszcze jednym module do IIS: Advanced Logging. Moze sie przydac, poniewaz serwer aplikacyjny dostaje zapytania od reverse proxy, przez co informacja w jego logach nie zawiera danych na temat faktycznie pytajacego klienta. Pytajacym jest przeciez zawsze reverse proxy. Reverse proxy dodaje jednak kilka swoich specjalnych naglówków, wsród których warto wymienic:

  • X-Forwarded-For – zawierajacy informacje o tym, kto przyslal zapytanie do reverse proxy zanim ten przekazal je dalej
  • X-Original-URL – sluzacy do przekazania zapytania w formie, która mialo zanim zostalo przetlumaczone na postac sluzaca do przeslania do serwera aplikacyjnego.

Pozostaje odpowiedziec sobie na dwa pytania: czy reverse proxy mi sie przyda i czy znajde cokolwiek lepszego i prostszego niz IIS. A potem po prostu dziala.

Autor: Grzegorz Tworek [MVP]