Reverse proxy w IIS

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:

• Serwer IIS. Najlepiej wersja 7 (Windows Server 2008) lub nowsza.
• Opcjonalny modul Advanced Request Routing (do pobrania ze stron Microsoft)
• Opcjonalny modul URL Rewrite (równiez do pobrania z Microsoft)

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.

 

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.

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]

Comments

• Anonymous
  January 01, 2003
  To zupełnie nie mój temat, ale mądrzejsi ode mnie sugerują, żeby zajrzeć tutaj: pepugmaster.blogspot.com/.../application-request-routing-dla.html

• Anonymous
  May 16, 2013
  Czy masz doświadczenia związane z tak skonfigurowanym proxy i udostęnianiem klientom Exchange przy użyciu RPC over https? Niestety dziwna implementacja tego w Exchange powoduje, że tylko niektóre reverse proxy sobie z tym radzą - opis problemu np. tutajissues.apache.org/.../show_bug.cgi

• Anonymous
  May 18, 2013
  Przy skonfigurowanym AAR występuje problem z RPC over HTTPS na Exchange 2k10 i 2k13 - z tego co wiem to nie ma obejścia problemu, Proponuję zaczekać na oficjalne stanowisko zespołu Exchange.