Przekierowanie portu a dostęp przez VPN: dokąd naprawdę trafia pakiet

Przekierowanie portu przepisuje cel i na tym poprzestaje; VPN najpierw opakowuje pakiet. Zobacz, którą warstwę zmienia każde z nich i co to oznacza dla HTTPS.

Dwa projekty, jedna aplikacja HTTPS, a pakiet w każdym podąża inną trasą. Przekierowanie portu zmienia, gdzie pakiet jest dostarczany, i resztę zostawia bez zmian. VPN najpierw niesie ten pakiet w innym pakiecie, więc nasłuchiwacz aplikacji widzi inne źródło i mniejszy maksymalny ładunek. Szyfrowanie, o którym się dyskutuje, jest obecne w obu przypadkach, bo aplikacja nadal działa po HTTPS; różni się to, kto może otworzyć połączenie i co może zaobserwować sieć pomiędzy. Ta różnica rozstrzyga większość praktycznych pytań.

Reguła DNAT przepisuje cel i na tym poprzestaje

Na bramie Linux opublikowanie usługi oznacza regułę w łańcuchu PREROUTING tabeli nat albo odpowiednik w nftables. Reguła dopasowuje publiczny adres i port, a następnie przepisuje cel na prywatny adres aplikacji. Adres źródłowy, port źródłowy i ładunek pozostają nietknięte, a conntrack zapisuje mapowanie, dzięki czemu odpowiedzi są przepisywane przy wyjściu. Zachowanie to tradycyjny model tłumaczenia adresów opisany w RFC 3022.

sudo iptables -t nat -A PREROUTING -d 203.0.113.10 -p tcp --dport 443 \
  -j DNAT --to-destination 10.20.30.40:443
sudo iptables -t nat -L PREROUTING -n -v
sudo conntrack -L -p tcp --dport 443

Nasłuchiwacz aplikacji nigdy nie dowiaduje się, że połączenie przyszło przez tłumaczenie. Widzi prawdziwy adres źródłowy klienta, co jest przydatne w logach dostępu i limitach szybkości, i odpowiada na adres prywatny, ponieważ conntrack odwraca mapowanie. Nic na tej trasie nie odszyfrowuje ani nie szyfruje ponownie: TLS nadal działa między klientem a własnym certyfikatem aplikacji.

Reguła ustala też tryby awarii, które napotkasz później. Jeśli brama przekazuje, ale host aplikacji nie ma żadnej trasy powrotnej do klienta, odpowiedzi wychodzą z niewłaściwym źródłem i uzgadnianie się zatrzymuje. Jeśli druga reguła pasuje pierwsza, kolejność decyduje o wyniku, a iptables -t nat -L -n -v pokazuje liczniki dowodzące, która reguła przejęła pakiet.

Tunel opakowuje pakiet, zanim nasłuchiwacz go zobaczy

VPN w ogóle nie publikuje aplikacji. Klient buduje zewnętrzny pakiet zaadresowany do publicznego adresu bramy, szyfruje w nim pakiet wewnętrzny, a brama odszyfrowuje i kieruje pakiet wewnętrzny do prywatnego celu. W WireGuardzie transport zewnętrzny to UDP, zwykle na wysokim porcie; w OpenVPN przez TCP 443 pakiet zewnętrzny wygląda jak TLS dla wszystkiego, co obserwuje trasę.

Wewnątrz tunelu pakiet wewnętrzny zachowuje prywatne adresy: adres tunelu klienta, powiedzmy 10.8.0.6, i aplikacja pod 10.20.30.40. Nasłuchiwacz widzi więc źródło z puli tunelu, a każdy klient dzieli tę bramę jako następny przeskok. Logi dostępu za VPN często pokazują bramę zamiast użytkownika właśnie z tego powodu, chyba że brama zachowuje pierwotne źródło.

Opakowanie kosztuje miejsce w nagłówku i to jedyna różnica na poziomie mechanizmu o mierzalnych skutkach. Zewnętrzny nagłówek IP plus UDP plus własny nagłówek WireGuarda zjadają MTU trasy, więc duże pakiety trzeba fragmentować albo wewnętrzny stos TCP musi ograniczyć swoje MSS. Przesył, który działa na przekierowanej trasie, może się zatrzymać na tunelu, gdy urządzenie pośredniczące odrzuci ICMP, które sygnalizowałoby mniejsze MTU.

ip route get 10.20.30.40
ping -M do -s 1400 10.20.30.40
sudo iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN \
  -j TCPMSS --clamp-mss-to-pmtu

Ekspozycję rozstrzyga się przy wejściu, a nie szyfrem

Oba projekty kończą się na tym samym nasłuchiwaczu TLS, więc oba dziedziczą ten sam certyfikat, te same wersje protokołu i to samo logowanie aplikacji. Zmienia się to, kto może rozpocząć uzgadnianie. Przy publicznym przekierowaniu każdy host, który osiągnie 203.0.113.10:443, dostaje uzgadnianie TCP i TLS ClientHello, zanim autoryzacja aplikacji zostanie w ogóle sprawdzona. Przy dostępie tylko przez tunel nasłuchiwacz jest osiągalny wyłącznie z adresów, które brama kieruje do tunelu, a SYN obcego ginie na polityce bramy.

Ta różnica dotyczy osiągalności, nie poufności. Przekierowana usługa HTTPS nie jest tekstem jawnym, a VPN nie usuwa potrzeby uwierzytelniania aplikacji: dopuszczenie do tunelu odpowiada na pytanie, czy urządzenie może wysyłać pakiety do tej sieci, podczas gdy aplikacja plikowa odpowiada, czy użytkownik może czytać dokument. Mieszanie obu tych rzeczy prowadzi do tego, że zespoły mają VPN dający całą sieć LAN i aplikację z jednym wspólnym hasłem.

Sprawdź nasłuchiwacz i politykę osobno, bo każde z nich może być szersze, niż zakładasz:

sudo ss -ltnp 'sport = :443'
sudo nft list ruleset
openssl s_client -connect 203.0.113.10:443 -servername files.example.com </dev/null

Jeśli ss pokazuje, że nasłuchiwacz jest powiązany z 0.0.0.0, aplikacja jest osiągalna skądkolwiek pozwalają na to routing i polityka firewalla, a przekierowanie to tylko jedna z dróg wejścia. Powiązanie z adresem prywatnym albo ograniczenie zakresu źródeł w firewallu to osobna decyzja od wyboru VPN i właśnie ona naprawdę zawęża ekspozycję.

Mierz trasę, nie etykietę

Gdy ktoś twierdzi, że przekierowanie jest szybsze, uczciwe porównanie utrzymuje wszystko inne na stałym poziomie: ten sam klient, ta sama sieć dostępu, ten sam plik, ta sama konfiguracja TLS, ten sam host aplikacji. Uruchom przesył dwa razy na każdej trasie i zapisz całkowity czas, liczbę błędów i responsywność, a nie wynik niezwiązanego testu szybkości.

curl -sS -o /dev/null -w '%{time_connect} %{time_appconnect} %{time_total}\n' \
  https://files.example.com/report.pdf
mtr -rwc 20 203.0.113.10
mtr -rwc 20 10.20.30.40

Te liczby oddzielają nawiązanie połączenia od czasu przesyłu, co ma znaczenie, bo dwie trasy zwykle różnią się opóźnieniem w obie strony i MTU, a nie kosztem szyfru. Praca TLS odbywa się na końcach w obu projektach, a tunel dodaje enkapsulację, inną trasę i być może bardziej obciążoną bramę. Jeśli trasa tunelu jest dłuższa albo jego brama jest obciążona, różnica należy do trasy, a nie do słowa szyfrowanie.

Wybierz politykę wejścia, której usługa naprawdę potrzebuje, a potem zdecyduj, czy zmierzona różnica uzasadnia jej zmianę. Publiczne przekierowanie pasuje do usługi przeznaczonej dla otwartego internetu, z ograniczeniami źródeł, aktualnym TLS i monitorowaniem przed nią. Dostęp tylko przez tunel pasuje do narzędzia wewnętrznego, którego użytkownicy są już zapisani, pod warunkiem że routing bramy i uprawnienia aplikacji są oba węższe niż cała sieć LAN.

Zanim uznasz projekt za gotowy, potwierdź cztery rzeczy: do jakiego adresu jest przypisany nasłuchiwacz, która reguła lub trasa wpuszcza pakiet, czy trasa powrotna działa z prawdziwego adresu klienta i czy duże ładunki przetrwają MTU. Każda z nich ma polecenie powyżej i żadnej nie odpowiada słowo bezpiecznie ani wykres przepustowości.

Powiązane artykuły