Reverse proxy na przykładzie serwera www Nginx

Reverse proxy jest technologią szeroko stosowaną we współczesnym internecie. Wiele osób z niej korzysta nie wiedząc nawet o tym, za sprawą popularnej usługi jaką jest cloudflare.com. W tym artykule postaram się przybliżyć tę tematykę na przykładzie serwera http jakim jest nginx.
Na początek musimy sobie jednak wyjaśnić czym jest proxy, czym różni się od wersji „odwróconej”. W najprostszym modelu, gdy użytkownik w swojej przeglądarce internetowej wpisuje jakiś adres domenowy, system operacyjny sprawdza za niego odwzorowanie domeny w DNS, a następnie przeglądarka kieruje się pod wskazany adres. Jest to wciąż bardzo popularny scenariusz z jakim mamy do czynienia na co dzień.

Czym jest proxy?

W prostym tłumaczeniu z języka angielskiego znaczy to tyle co pełnomocnik, w nomenklaturze IT bardziej właściwym terminem będzie pośrednik. Jest to zatem mechanizm, który powoduje, że użytkownik nie łączy się bezpośrednio z wybranym serwerem internetowym. Pomiędzy przeglądarką, a serwerem serwującym stronę internetową pojawia się usługa pośrednicząca, która z natury ukrywa tożsamość klienta.

Tego typu rozwiązania od wielu lat ułatwiają życie osobom, które chcą ukryć swoją tożsamość. Często służą od omijania blokady regionalnej, bądź do posługiwania się różnymi adresami IP. Liczba zastosowań tego mechanizmu jest długa, jednak my dzisiaj się skupimy na pewnej odmianie proxy, która zdobyła ogromną popularność po stronie serwera, a nie klienta.

Reverse proxy

Podobnie jak w klasycznej wersji, tak samo i tutaj mamy do czynienia z mechanizmem pośredniczącym. W tym przypadku proxy jest odwrócone i służy na rzecz serwera. Ta wersja pośredniczenia w połączaniach pomiędzy klientem, a serwerem znalazła szerokie zastosowanie w technologiach wykorzystywanych do utrzymywania infrastruktury webowej.

Zastosowanie tego mechanizmu posiada wiele zalet, z których największe to:

• bezpieczeństwo – bez wątpienia wplecenie dodatkowej usługi przed serwerem http wpływa na zwiększenie poziomu bezpieczeństwa. Dzięki reverse proxy możliwe jest ukrycie przed światem prawdziwej adresacji serwera docelowego. Można ukryć przed klientem praktycznie całą infrastrukturę która jest wykorzystywana przez system. Częstym stosuje się odpowiednie reguły firewalla, które zezwalają na ruch do strony internetowej tylko z wybranego zakresu adresacji. W przypadku cloudflare powinniśmy zadbać o dopuszczenie całej puli adresów cloudflare, również tych pochodzących z IP6.
• cachowanie – istnieją narzędzia, które implementują mechanizmy cachowania na poziomie reverse proxy. Najbardziej znanym rozwiązaniem jest Varnish Cache. Jest to potężne oprogramowanie, które posiada bardzo wiele przydatnych funkcji: modyfikacja treści oraz nagłówków, wsparcie dla ESI(Edge Side Includes), load balancing oraz wiele innych. W domyślnej konfiguracji Varnish nie posiada jedynie wsparcia dla ssl.
• high availbility – wysoką dostępność zapewnia się w dzisiejszym świecie na kilka sposobów, jednak najpopularniejszym rozwiązaniem jest skalowanie horyzontalne. Ta praktyka wymaga posiadania tzw. load balancera. Najpopularniejszymi rozwiązaniami tego typu jest Nginx oraz HAProxy

Nieoczywiste zastosowania

Dzięki swojej elastyczności mechanizm reverse proxy znalazł szereg zastosowań, które na pierwszy rzut oka mogą się wydawać dziwne.

Jedna domena, wiele aplikacji

Czasami zdarza się, że zachodzi konieczność podczas tworzenia aplikacji internetowych wydzielenia jakiegoś podkatalogu domeny, w celu serwowania zupełnie innej strony. W klasycznej konfiguracji serwera HTTP również jest to możliwe, jednak w momencie gdy musimy wydzielić część strony internetowej jako microservice w zupełnie inne miejsce, to pojawia się problem. Wtedy z pomocą przychodzi reverse proxy, które pozwala na przekierowanie ruchu w kilka różnych miejsc docelowych w zależności od żądanego URI.

Poniżej przedstawię konfigurację reverse proxy dla takiego scenariusza na przykładzie Nginx.
Załóżmy że mamy poprawnie zainstalowany serwer nginx, dla którego utworzymy nowego vhosta

sudo nano /etc/nginx/sites-available/przyklad.pl.conf

server {
listen      80;
server_name przyklad.pl www.przyklad.pl;
index       index.php;
root        /var/www/przyklad.pl/web 

location / {
try_files $uri $uri/ /index.php?$query_string;
}

location /blog {
proxy_pass http://10.0.0.100:80;
proxy_http_version                 1.1;
proxy_cache_bypass                 $http_upgrade;

proxy_set_header Upgrade           $http_upgrade;
proxy_set_header Connection        "upgrade";
proxy_set_header Host              $host;
proxy_set_header X-Real-IP         $remote_addr;
proxy_set_header X-Forwarded-For   $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Forwarded-Host  $host;
proxy_set_header X-Forwarded-Port  $server_port;

}

W powyższym pliku konfiguracyjnym mamy obsługę dla domeny przyklad.pl. Wszystkie requesty są kierowane do pliku index.php, który w tym przypadku pełni rolę front controllera dla jakiejś aplikacji internetowej. Ciekawe rzeczy dzieją się jednak później. Dla lokalizacji /blog zdefiniowano osobną konfigurację, która odpowiada za przekazywanie ruchu w zupełnie inne miejsce. Dzięki takiemu rozwiązaniu „podzieliliśmy” domenę, co w konsekwencji pozwoli nam na hostowanie strony internetowej jaką jest blog na zupełnie innym serwerze.
Na końcu zadbaliśmy jeszcze o ustawienie poprawnych nagłówków http, dzięki którym serwer docelowy będzie w stanie odczytać adres źródłowy zapytania.

Aplikacje internetowe uruchamiane przy pomocy dockera

Od kilku lat mechanizmy konteneryzacji święcą triumfy w świecie infrastruktury serwerowej. Technologią, która w dużej mierze stoi za tymi sukcesami niewątpliwie jest docker. Dzięki swojej popularności, ogromna ilość aplikacji, nie tylko internetowych, jest publikowana w formie obrazów dockera. Takie obrazy mogą służyć do rozwijania własnego oprogramowania, ale mogą być uruchamiane również użytkowo.
Zdarza się często, że administratorzy nie chcąc uruchamiać klastrów kubernetes dla pojedynczych kontenerów, decydują się na skorzystanie z mechanizmów reverse proxy.
Załóżmy, że na jednej maszynie chcemy uruchomić kilka stron internetowych, które zostały wcześniej „zdockeryzowane”. Każda z tych aplikacji ma domyślnie działać na porcie 80. Pojawia się problem, w którym jedna maszyna nie jest w stanie zapewnić tego samego portu dla wielu aplikacji webowych jednocześnie. Tutaj z pomocą przychodzi reverse proxy. Wystarczy każdą stronę www uruchomioną jako kontener dockera ustawić na innym porcie np. 8080, 8081, 8082 etc. Wtedy pozostaje nam już tylko odpowiednia konfiguracja nginx jako reverse proxy, aby każda ze stron internetowych mogła działać prawidłowo.

Podsumowanie

Nginx dzięki swojej elastyczności oraz wydajności daje nam ogromne możliwości również w kontekście reverse proxy. Ten mechanizm właściwie stanowi już standard we współczesnych stronach www. Pojawienie się takich usług jak cloudflare zdecydowanie przyspieszyło proces implementacji tego mechanizmu również w mniejszych aplikacjach internetowych. Dzisiaj nie trzeba już być wysokiej klasy specjalistą, aby zapewnić szybko i sprawnie wysoki poziom bezpieczeństwa dla swojej witryny www.