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:

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]

Comments (3)

  1. Anonymous says:

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

  2. Wojciech Ściesiński says:

    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. tutaj

    issues.apache.org/…/show_bug.cgi

  3. Piotrek says:

    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.

Skip to main content