Które porty VPN otworzyć na zaporze: protokół po protokole

Dwie osobne reguły decydują, czy tunel VPN przetrwa zaporę: port, na który dzwoni klient, oraz protokół, który niesie ładunek. Otwórz tylko pierwszą i tunel się uwierzytelni, ale potem nie przeniesie żadnych danych. Minimum to jeden port TCP i GRE dla PPTP, dwa porty UDP i ESP dla L2TP/IPsec oraz IKEv2, i jeden port dla SSTP, OpenVPN i WireGuard. Kierunek, śledzenie stanu i NAT decydują o reszcie.

Zacznij od portu, na który dzwoni klient

Każda rodzina ma punkt wejścia, z którym klient kontaktuje się pierwszy, i właśnie ten punkt musi nazwać twoja reguła zezwolenia. Klienci PPTP łączą się z TCP 1723. L2TP/IPsec zaczyna IKE na UDP 500 i przechodzi na UDP 4500, gdy używane jest przechodzenie przez NAT, a sama ramka L2TP znajduje się na UDP 1701 wewnątrz tunelu. SSTP opakowuje sesję w TLS na TCP 443, IKEv2 negocjuje na UDP 500 i 4500, OpenVPN domyślnie używa UDP 1194, ale często jest przenoszony na TCP 443, a WireGuard nasłuchuje na UDP 51820.

Traktuj te liczby jako wartości domyślne, a nie stałe właściwości. Interfejs WireGuard używa dowolnego portu nasłuchu, który deklaruje jego konfiguracja, a serwer OpenVPN może siedzieć na dowolnym porcie wybranym przez administratora. Przeczytaj konfigurację serwera, zanim napiszesz regułę, bo zapora otwarta dla 1194 nic nie daje serwerowi przeniesionemu na 443.

Trzecia kolumna to miejsce, w którym większość zgłoszeń zmian idzie nie tak. Reguła istnieje, ale wskazuje zły cel, zły kierunek albo zły transport.

GRE i ESP to numery protokołów, nie porty

GRE i ESP nie mają żadnych portów, więc formularz zapory, który przyjmuje tylko numery portów, nie potrafi ich wyrazić. GRE to protokół IP 47, a ESP to protokół IP 50, oba dopasowywane przez pole protokołu w nagłówku IP. Reguła zapisana jako port TCP 47 nie pasuje do niczego, i tak polityka PPTP wygląda poprawnie, a mimo to odrzuca każdy pakiet po uścisku dłoni.

Rutery domowe ukrywają to za polem przekazywania, które instaluje regułę protokołu, a w przypadku GRE także pomocnika NAT potrzebnego do mapowania przepływu. Na prawdziwej zaporze dodajesz protokół sam: zezwól na protokół IP 47 do serwera PPTP, zezwól na protokół IP 50 do bramy IPsec. Gdzie platforma nie oferuje pola protokołu, wyjściem jest enkapsulacja, dlatego IKEv2 może wrócić na UDP 4500 i dlatego OpenVPN i WireGuard nigdy nie trafiają na ten problem.

Sprawdź, do czego reguła faktycznie pasuje, zanim obwinisz klienta. Licznik pakietów, który na bramie pozostaje na zerze, mówi, że reguła nigdy nie zadziałała, i żadna reinstalacja po stronie klienta tego nie zmieni.

Kierunek, stan i NAT zmieniają odpowiedź

Klient dzwoniący na zewnątrz i brama nasłuchująca do wewnątrz to różne wymagania, a ta sama lista portów może być poprawna w jednym kierunku i błędna w drugim. Zapora ze śledzeniem stanu obserwuje przepływ UDP na 500 i 4500 i wpuszcza odpowiedzi z powrotem bez drugiej reguły. ESP i GRE nie niosą portów, więc urządzenie NAT nie ma się czego uchwycić i potrzebuje pomocnika albo enkapsulacji, aby śledzić sesję.

Przechodzenie przez NAT to część, która bywa pomijana. IKEv2 zaczyna na UDP 500, wykrywa urządzenie NAT i kontynuuje na UDP 4500, więc polityka zezwalająca tylko na 500 daje tunel, który się zestawia i potem cichnie. L2TP/IPsec wykonuje ten sam ruch. Jeśli przechwycenie pokazuje pierwszą wymianę, ale nie ciągły ruch, poszukaj reguły, która zatrzymuje się na 500.

Zapisuj kierunek przy każdej regule. „Zezwól na UDP 4500” nic nie znaczy, dopóki nie powiesz skąd dokąd, a reguła poprawna dla klienta mobilnego zwykle jest błędna dla peera lokacja-lokacja.

Sprawdź każdą ścieżkę przechwyceniem

Uruchom przechwycenie na bramie, nie na kliencie: klient rejestruje tylko to, co dotarło. Te filtry obejmują powyższe rodziny i pokazują, którego etapu brakuje:

sudo tcpdump -ni any tcp port 1723
sudo tcpdump -ni any udp port 500 or udp port 4500
sudo tcpdump -ni any proto gre
sudo tcpdump -ni any proto 50

Czytaj wynik jako sekwencję. Gdy negocjacja się pojawia, a protokół ładunku nie, odrzucenie następuje gdzieś między klientem a bramą. Gdy widać oba, a strona nadal zawodzi, zapora nie jest już podejrzanym; zajrzyj do trasowania, DNS albo puli adresów przekazanej klientowi.

Na maszynie bez tcpdump te same dowody dają liczniki interfejsu i reguł. Bajty wchodzą, ale nie wychodzą na interfejsie tunelu — to wskazuje na drogę powrotną, a nie na początkową regułę zezwolenia.

Zostaw zbiór reguł, którego możesz bronić

SSTP na TCP 443 jest nierozróżnialny od zwykłego HTTPS dla każdego filtra opartego na portach, i o to właśnie chodzi, gdy sieć dopuszcza tylko ruch WWW. Dlatego reguła dla 443 powinna wskazywać bramę jako cel, a nie cały internet. Usuwaj tymczasowe reguły z dowolnego do dowolnego, gdy tylko tunel zacznie działać. Zapisz, która reguła pasowała, numer protokołu tam, gdzie jest, i kierunek, aby następna osoba zaczynała od dowodów.

Bramy chmurowe typu punkt-lokacja czynią wybór widocznym: pobrany profil używa albo SSTP na 443, albo IKEv2 na 500 i 4500, i należy otworzyć tylko to, co profil faktycznie wybiera. PPTP nie jest wart wyjątku dla GRE w nowoczesnej sieci, ponieważ operatorzy komórkowi często odrzucają protokół 47 niezależnie od zapory. Przed zamknięciem zgłoszenia potwierdź, że reguła pasuje do portu w konfiguracji serwera, że pole protokołu jest ustawione tam, gdzie rodzina go potrzebuje, i że celem jest brama, a nie dowolny adres.