Proxy HTTP, tunel SSH czy VPN: wybierz właściwą warstwę

Zapytaj trzech inżynierów, jak dostać się do wewnętrznej usługi, a dostaniesz trzy projekty: proxy WWW, tunel SSH albo pełny VPN. Wszystkie trzy potrafią udostępnić zdalną usługę i wszystkie trzy potrafią sprawić, że ruch będzie wyglądał, jakby pochodził z innego miejsca. Różnice wychodzą później, gdy używany protokół nie jest tym, który zakłada wybrane narzędzie. Projekt, który przechodzi szybki test w przeglądarce, często zawodzi w aplikacji, dla której powstał pomysł.

Zdecyduj na podstawie dwóch faktów: jakie protokoły muszą przejść i kto potrafi rozwiązać nazwy, których to dotyczy. Reszta to preferencje.

Proxy przenosi tylko to, co rozumie

Proxy WWW parsuje protokół, dla którego powstało. Klient przekazuje mu żądanie, a ono przekazuje je dalej, więc aplikacja bez ustawień proxy w ogóle nie bierze udziału. Dla HTTPS klient potrzebuje nieprzejrzystego kanału, który proxy zapewnia przez CONNECT, a nie przez czytanie żądania.

Dynamiczny forward SSH otwiera lokalny port mówiący SOCKS, a ten port przekazuje strumień TCP do dowolnego miejsca wskazanego przez klienta. Protokoły oparte na TCP zwykle przez niego działają. UDP nie, chyba że narzędzie doda obsługę jawnie. Lokalny forward jest jeszcze węższy: jeden lokalny port mapowany na jeden stały host i port, co obsługuje jedną znaną usługę i nic więcej.

ssh -D 1080 user@bastion
ssh -L 8443:fileserver.internal:443 user@bastion

VPN przenosi pakiety. Wszystko, co klient kieruje do tunelu, przez niego przechodzi, łącznie z UDP i ICMP, dlatego pasuje do wymagania sieciowego, a nie do pojedynczego połączenia.

Ktoś musi rozwiązać nazwę

Gdy nazwa docelowa istnieje tylko w DNS zdalnej sieci, ten element, który wykonuje zapytanie, musi widzieć tę strefę. Proxy WWW samo wykonuje zapytanie, więc wewnętrzna nazwa działa przez nie nawet wtedy, gdy laptop w ogóle nie potrafi jej rozwiązać. SOCKS potrafi zachować się tak samo, ale tylko wtedy, gdy klient przekaże nazwę, zamiast łączyć się z adresem, który już rozwiązał. Ten wybór należy do klienta, nie do serwera.

curl pokazuje ten podział jasno: jedna flaga przekazuje nazwę hosta proxy, druga rozwiązuje ją najpierw lokalnie. Przy lokalnym rozwiązywaniu nazwa dostępna tylko wewnętrznie zawodzi, zanim dotknie się tunelu, a błąd obwinia proxy o coś, co naprawdę było decyzją DNS.

VPN wybiera trzecią drogę: instaluje prywatny resolver i domenę wyszukiwania obok tras. To wygodne i tworzy znajome złudzenie: trasa, która istnieje, z resolverem, który nie odpowiada, wygląda dokładnie jak martwy tunel, choć pakiety docierają na drugą stronę.

Gdy sieć pozwala tylko na jedno wyjście

Wiele sieci firmowych dopuszcza połączenia wychodzące wyłącznie przez uwierzytelnione proxy WWW. OpenVPN i SSH można tam uruchomić, pierwsze przez tunelowanie własnego transportu przez proxy, drugie przez polecenie proxy uruchamiające mały pomocnik CONNECT.

Tunele zbudowane na TCP przetrwają to ograniczenie, a VPN oparty na UDP nie, co wyjaśnia mnóstwo konfiguracji, które działają w domu i zawodzą w biurze. Drugi koszt łatwo przeoczyć: tunel TCP niesiony w proxowanym połączeniu TCP ma teraz dwie warstwy retransmisji, a przy stratach ten duet zatyka się w sposób, którego żadna warstwa nie tworzy sama.

Łączenie pośredników to inne pytanie niż wybór warstwy. Dodanie drugiego proxy albo Tora zmienia to, kto co obserwuje, a pozycja w łańcuchu decyduje, który przeskok widzi szyfrogram.

Kolejność ma większe znaczenie niż liczba przeskoków. Zewnętrzny przeskok widzi zaszyfrowany strumień, a wewnętrzny widzi jawny tekst, który jest w nim niesiony, więc łańcuch jest tak prywatny, jak jego najmniej staranne ogniwo. Mieszanie protokołów między przeskokami nie poprawia tego automatycznie. Przeważnie tylko utrudnia rozumowanie o trybach awarii.

Podrobiony adres nie jest jedną z opcji

Tworzenie pakietów z cudzego adresu źródłowego niczego użytecznego nie osiąga: odpowiedzi idą do prawdziwego właściciela, a większość sieci po prostu odrzuca taki ruch. Pośrednik jest konieczny właśnie dlatego, że źródła nie można wymyślić, i to jest uczciwe uzasadnienie wszystkich trzech projektów.

To zarazem ogranicza, co którykolwiek z nich może twierdzić. Wyglądanie na pochodzące z konkretnego adresu to pytanie o to, gdzie ten adres jest legalnie przydzielony i kto może go trasować, a nie o to, które narzędzie potrafi sfałszować nagłówek. Jeśli projekt zakłada coś innego, założenie zawodzi u pierwszego dostawcy, który je odfiltruje. Zapisz założenie, aby awarię można było rozpoznać, gdy nadejdzie.

Decyduj według protokołów i nazw

Wybierz proxy, gdy jeden klient WWW potrzebuje jednej usługi WWW i ma ustawienia proxy. Wybierz tunel SSH, gdy wystarczy kilka znanych usług TCP i dostęp SSH już istnieje. Wybierz VPN, gdy kilka aplikacji, ruch nie-TCP, prywatny DNS lub wielokrotnie używalna ścieżka są częścią wymagania.

Potem sprawdź prawdziwym klientem i prawdziwą nazwą. Wczytanie strony przez proxy nie uczy cię niczego o UDP, a uruchomienie jednego narzędzia przez SOCKS nie uczy cię niczego o resolverze systemowym. Odczytaj, jaki adres lokalny związał proces i który resolver odpowiedział. Na tym polega różnica między ścieżką, która działa, a taką, która przypadkiem zadziałała raz.