Podzielony tunel PPTP nie działa: najpierw napraw ścieżkę GRE

Obserwuj, jak podnosi się połączenie PPTP, i łatwo uwierzyć, że trudna część jest zrobiona: klient się uwierzytelnia, pojawia się adapter ppp0 lub WAN Miniport, a okno stanu staje się zielone. Potem pierwsze żądanie do hosta wewnętrznego kończy się przekroczeniem czasu i wina spada na profil. W praktyce trzeba oczyścić dwie niezależne warstwy: transport zewnętrzny, który przenosi TCP 1723 i GRE, oraz politykę wewnętrzną, która decyduje, które cele korzystają z interfejsu PPP. Zielony stan dowodzi tylko, że pierwsza warstwa wynegocjowała; o drugiej nie mówi nic.

Śledź klienta od profilu do gniazda sterującego

Otwórz dziennik klienta i znajdź miejsce, w którym kontaktuje się z serwerem. PPTP najpierw otwiera połączenie TCP na port 1723 i negocjuje parametry tunelu tym kanałem. Jeśli ten krok się nie powiedzie, nic później nie ma znaczenia, a błąd zwykle podaje adres serwera lub przekroczenie czasu.

Potwierdź połączenie sterujące w sieci, zanim dotkniesz jakiejkolwiek trasy. Na kliencie lub porcie lustrzanym przechwyć TCP 1723 dla jednej próby połączenia:

sudo tcpdump -ni any 'tcp port 1723' -c 20

Zakończony uścisk dłoni i ustanowiona sesja oznaczają, że zewnętrzny kanał sterujący działa. SYN, który nigdy nie dostaje SYN-ACK, wskazuje na zaporę, zły adres serwera lub dostawcę filtrującego port. Uścisk dłoni z natychmiastowym resetem często oznacza, że serwer odrzucił dane logowania lub typ tunelu.

GRE to drugi protokół, a nie port

PPTP przenosi ładunek PPP w rozszerzonym GRE, protokole IP 47, który nie ma numeru portu, jaki router mógłby śledzić. Dlatego reguła zezwalająca na TCP 1723 wciąż może zostawić tunel bez ścieżki danych. Urządzenia NAT ze stanem muszą rozumieć identyfikator wywołania w GRE, aby mapować odpowiedzi, a wiele tego nie robi. Specyfikacja PPTP trzyma kanał sterujący i ładunek GRE jako osobne części, i twój plan testów też tak musi robić.

Obserwuj protokół 47 w tym samym przechwycie, a potem porównaj to, co wychodzi, z tym, co wraca:

sudo tcpdump -ni any 'proto gre' -c 20

Pakiety wychodzące bez odpowiedzi, gdy TCP 1723 pozostaje zdrowy, to klasyczny podpis zablokowanego GRE. Przekazywanie PPTP na routerze konsumenckim jest funkcją tego konkretnego firmware, więc działająca sieć hotelowa niczego nie dowodzi o następnej. Jeśli router nie oferuje przekazywania i nie możesz go zmienić, problemem jest wybór protokołu, a nie tablica tras.

Udowodnij, że tunel przenosi jeden pakiet

Gdy GRE płynie, negocjacja PPP przypisuje adres interfejsowi klienta. Przeczytaj przypisanie, zamiast je zakładać:

ip -4 addr show ppp0

Pinguj adres peera pokazany jako cel łącza punkt-punkt. Odpowiedź na tym etapie dowodzi, że enkapsulowana ścieżka działa od końca do końca i że serwer odpowiada wewnątrz tunelu. Jeśli peer odpowiada, a hosty wewnętrzne nie, transport zewnętrzny jest w porządku, a awaria przeniosła się do środka.

Zrób to przed dodaniem jakiejkolwiek trasy dzielonej. Zmiana trasy wykonana przy zepsutym transporcie tworzy drugą zmienną i ukrywa pierwszą.

Napisz politykę dzieloną, wraz z DNS

Routing dzielony to lista decyzji, a nie pole wyboru. Każdy prefiks prywatny, który musi przejść przez tunel, potrzebuje trasy przez interfejs PPP, a każdy prefiks, który ma pozostać lokalny, musi w niej nie występować. Trasa do podsieci aplikacji bez pasującej trasy do jej prywatnego resolvera to częsty sposób tworzenia awarii, która wygląda jak zepsuta aplikacja.

Sprawdź decyzję, którą jądro podejmuje dla jednego adresu w każdej kategorii:

ip route get 10.20.5.10
ip route get 203.0.113.25

Pierwszy powinien wskazać ppp0, drugi zwykłą bramę. Jeśli oba wskazują ten sam interfejs, polityka wcale nie jest dzielona. Dodaj adres samego serwera DNS do listy tunelu, inaczej rozwiązywanie nazw dla hostów wewnętrznych wychodzi przez lokalny resolver i nie zwraca nic użytecznego.

Powtarzalna kontrola w pięciu krokach

Uruchamiaj warstwy po kolei i zatrzymaj się na pierwszej, która zawiedzie: kanał sterujący, widoczność GRE, odpowiedź peera PPP, trasa dzielona dla jednego adresu wewnętrznego i żądanie aplikacji przez tunel. Każdy krok ma własne polecenie, więc awaria jest przypisywalna, a nie zagadkowa.

Kompaktowa wersja dla klienta Linux wygląda tak:

sudo tcpdump -ni any 'tcp port 1723 or proto gre' -c 40
ip -4 addr show ppp0
ping -c 3 192.0.2.1
ip route get 10.20.5.10

W systemie Windows obowiązuje ta sama kolejność z route print i stanem adaptera pokazanym w kliencie. PPTP to przestarzały protokół, a jeśli serwer oferuje SSTP lub IKEv2, przejście jest zwykle lepszym wykorzystaniem czasu niż strojenie ścieżki, która zależy od przejścia protokołu 47 na każdym skoku. Sprawdź certyfikat i umowę uwierzytelniania zamiennika, zamiast kopiować stary profil do nowego wydania.