Tunel VPN nigdy się nie łączy: gdzie naprawdę zatrzymują się pakiety

Tunel, który nigdy nie powstaje, zostawia pusty dziennik po obu stronach. Sprawdź, czy GRE, ESP lub UDP 4500 jest odrzucany, i rozpoznaj NAT operatora, zanim edytujesz serwer.

Klient wciąż ponawia próby, dziennik zatrzymuje się przed zakończeniem uzgadniania, a serwer nie zapisuje zupełnie niczego. Ten wzorzec odsuwa uwagę od poświadczeń i kieruje ją na ścieżkę: coś między dwoma końcami odmawia przenoszenia protokołu, którego potrzebuje tunel. Ustal, gdzie zatrzymują się pakiety, zanim dotkniesz którejkolwiek z dwóch konfiguracji, ponieważ filtrowany protokół i błędne hasło dają w większości klientów ten sam uprzejmy błąd. Testy są uporządkowane według kosztu, najtańszy pierwszy.

Udowodnij, gdzie zatrzymuje się ruch

Przechwytuj jednocześnie na interfejsie wyjściowym klienta i na serwerze. Porównaj to, co wyszło, z tym, co dotarło, i zanotuj, w którym kierunku pojawia się różnica.

Nic na serwerze oznacza, że ścieżka lub pierwszy NAT odrzuca ruch, natomiast przychodzące pakiety bez odpowiedzi wskazują na zaporę na serwerze lub nieistniejącą trasę powrotną. Router, który często kończy tunele, rzadko prowadzi użyteczny dziennik, więc przechwycenie staje się zapisem. Zanotuj port docelowy i numer protokołu, ponieważ oba błędy wyglądają w oknie klienta identycznie.

PPTP umiera bez protokołu 47

PPTP przenosi sterowanie przez TCP 1723, a dane wewnątrz GRE, który jest protokołem IP 47, a nie numerem portu. Przekierowanie tylko 1723 daje klasyczny wynik: połączenie się uwierzytelnia, a potem cichnie, ponieważ nie ma reguły dla protokołu przenoszącego ładunek. Klient nie potrafi odróżnić tego od odrzuconego hasła, dlatego przechwycenie musi nastąpić przed zmianami konfiguracji.

Przepuszczanie działa w kierunku przeciwnym do przekierowania przychodzącego, a firmware wystarczająco często używa jednej etykiety dla obu, by wszystkich zdezorientować. Na kliencie Linux lokalna zapora może odrzucić GRE znacznie wcześniej, zanim router w ogóle weźmie udział, więc protokół 47 potrzebuje własnej reguły, a pomocnik conntrack musi być załadowany. ufw w Ubuntu trzyma te reguły w pliku before, ponieważ zwykłe reguły allow nie potrafią wyrazić numeru protokołu. Następnie przeładuj zaporę zamiast restartować maszynę.

# /etc/ufw/before.rules, inside *filter
-A ufw-before-input -p gre -j ACCEPT
sudo ufw allow 1723/tcp
sudo modprobe nf_conntrack_pptp
sudo conntrack -L | grep gre

L2TP i IPsec za dwoma NAT

L2TP wewnątrz IPsec wymaga UDP 500 do wymiany kluczy, UDP 4500 po wykryciu NAT i ESP jako protokołu 50. Każdy z nich jest filtrowany niezależnie, więc reguła zezwalająca na jeden niczego nie dowodzi o pozostałych dwóch. Dwa routery w szeregu tłumaczą każdy pakiet dwukrotnie, a końce nie są już zgodne co do tego, co uzgodniono.

Połącz zewnętrzny modem w most, albo wyłącz NAT na wewnętrznym routerze, aby publiczny adres dotarł do urządzenia kończącego tunel. Tam, gdzie żadne z nich nie jest możliwe, tunel trzeba zainicjować od wewnątrz granicy podwójnego NAT, a nie kończyć go tam.

Sieci operatorów i współdzielenie adresów

Adres WAN w zakresie 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 lub 100.64.0.0/10 oznacza, że router nie ma adresu publicznego i żadne przekierowanie przychodzące z internetu do niego nie dotrze. NAT na poziomie operatora dodatkowo filtruje protokoły, których się nie spodziewa, a GRE pada często na łączach mobilnych. Porównaj adres WAN na samym routerze, a nie ten, który serwis wyszukiwania podaje dla klienta za nim.

Uruchomienie tego samego routera na linii kablowej jednym testem oddziela ustalenie dotyczące operatora od błędu konfiguracji. Tam, gdzie operator odmawia protokołu, pozostają opcje innego transportu na 443 lub tunelu zainicjowanego od wewnątrz.

Przeczytaj listę nasłuchujących, zanim zamkniesz porty

Niepokojące skanowanie portów to często tylko zestaw funkcji dostarczany jako aktywny. Zinwentaryzuj nasłuchujące, przypisz każdy gniazdo do funkcji, a następnie wyłącz funkcję zamiast blokować port, żeby oba widoki się nie rozjechały.

ss -lntup
systemctl list-units --type=service --state=running | grep -i vpn
nc -vz 203.0.113.10 1723
nc -vzu 203.0.113.10 4500

Domyślne ustawienia SoftEther to dobry przykład: TCP 443, 992 i 5555, a funkcje L2TP/IPsec i tunelu DNS dodają własne gniazda. Wyłączenie tych funkcji usuwa nasłuchujące zamiast je ukrywać, a test z zewnętrznego hosta mówi, czy operator w ogóle przepuszcza port. Nasłuchujący, który odpowiada lokalnie, może nadal być zamknięty wyżej, więc porównaj własny adres WAN routera z tym, co raportuje zewnętrzna usługa.

Powiązane artykuły