Jeden port OpenVPN, trzy usługi: dlaczego porty wewnętrzne mają znaczenie

Jedna sesja SSH, jedna aplikacja webowa i jedno wyszukiwanie nazwy mogą dzielić jedno połączenie VPN bez walki o porty. Klient buduje jeden zaszyfrowany strumień do bramy, a każda rozmowa aplikacji podróżuje w jego wnętrzu. Na zewnątrz widoczny jest tylko własny transport tunelu i jego port. Wewnątrz każda usługa zachowuje własny port i nadal potrzebuje własnego uprawnienia.

Co niesie zewnętrzny strumień i co ukrywa

Klient opakowuje każdy pakiet w transport tunelu, zanim opuści on maszynę. Ten zewnętrzny strumień ma jeden port docelowy, ustalony podczas konfiguracji VPN. Wewnątrz opakowania każdy oryginalny pakiet zachowuje adres i port usługi, do której jest skierowany. Brama zdejmuje opakowanie i routuje według wewnętrznego nagłówka, więc cel widzi zwykłego klienta przychodzącego z sieci.

Przechwycenie na interfejsie WAN pokazuje więc jedną rozmowę, a nie trzy. Porty wewnętrzne pojawiają się dopiero po dekapulacji. Dlatego jedno otwarcie zapory może nieść SSH, HTTPS i DNS jednocześnie.

# WAN side: one outer tuple, whatever the inner services are
tcpdump -ni wan0 'udp port 443'
# tunnel side: the inner tuples appear after decapsulation
tcpdump -ni tun0

Dokumentacja TUN/TAP opisuje przekazanie, w którym routowane urządzenie TUN przekazuje pakiety IP między jądrem a procesem w przestrzeni użytkownika. To przekazanie sprawia, że wewnętrzny nagłówek jest widoczny dla kodu routingu i zapory bramy. Wyjaśnia też, dlaczego port zewnętrzny nic nie mówi o tym, które usługi są dozwolone.

Przekierowanie NAT należy do nasłuchu, a nie do aplikacji

Samodzielnie hostowana brama za NAT IPv4 potrzebuje jednego tłumaczenia przychodzącego: publiczny adres i port są mapowane na nasłuch VPN. Żadna reguła nie jest potrzebna dla SSH, HTTPS ani DNS tylko dlatego, że użytkownicy tunelu do nich docierają. Publikowanie tych portów ujawniłoby usługi, które tunel już chroni. Reguła przekierowania opisuje osiągalność nasłuchu, a nie uprawnienie dla czegokolwiek wewnątrz.

Zachodzi też odwrotność. Otwarcie portu tunelu nie ujawnia niczego innego, więc usługa osiągalna tylko przez tunel zachowuje swoją publiczną powierzchnię zamkniętą. To rozdzielenie jest zwykle powodem trzymania usługi prywatnie.

Wewnętrzna polityka to miejsce, w którym dostęp jest faktycznie rozstrzygany

Szyfrowanie chroni ścieżkę; nie upoważnia celu. Trasy klienta wybierają, które prefiksy wchodzą do tunelu, polityka przekazywania bramy decyduje, czy pakiety mogą go opuścić, a zapora i logowanie celu decydują, czy usługa odpowie. DNS jest najjaśniejszym przypadkiem: przenoszenie zapytań nie sprawia, że resolver przyjmie je z twojej puli klientów. Każda warstwa może odmówić niezależnie.

Testuj każdą usługę osobno przez tunel. Udane wyszukiwanie nic nie mówi o porcie webowym, a udane żądanie webowe nic nie mówi o SSH.

dig @10.40.0.53 app.corp.example
nc -vz 10.40.0.10 8443
ssh -p 2222 [email protected]

Gdy tunel działa, a wszystko zawodzi, najpierw przeczytaj tablicę tras klienta. Gdy jedna usługa zawodzi, a inne działają, usterka tkwi w tym celu. Te dwa spostrzeżenia wskazują na różnych właścicieli, a mieszanie ich marnuje czas.

WireGuard wyznacza tę samą granicę

WireGuard nazywa swój zewnętrzny nasłuch ListenPort, a wewnętrzna aplikacja nadal używa portu usługi, którego potrzebuje. AllowedIPs to zbiór trasowanych prefiksów, a nie lista dozwolonych portów usług. Czytanie go jako listy dozwolonych portów daje reguły, które nie zgadzają się z tym, co robi tunel. Nazewnictwo jest inne; warstwowanie nie.

Zezwól usłudze w polityce lokalnego wejścia, gdy działa na samym punkcie końcowym, albo w polityce przekazywania, gdy znajduje się za tym punktem. To rozróżnienie decyduje, który zestaw reguł widzi pakiet.

Ogólny kształt to jeden transport zewnętrzny z wieloma rozmowami wewnętrznymi. Produkty wymagające kilku wymian zewnętrznych lub innego protokołu IP przypominają, że wzorzec jednego publicznego portu opisuje ten projekt, a nie każdy VPN.