Brak przepuszczania PPTP: napraw błąd 807 Windows VPN

Przekierowanie TCP 1723 często otwiera pierwszą część PPTP, a resztę zostawia zepsutą, więc Windows nadal zwraca błąd 807 przy próbie. Kolejnym odruchem jest dodanie reguły dla portu 47, i właśnie ten krok marnuje popołudnie: GRE to numer protokołu w nagłówku IP, a nie port, który tabela przekierowań może dopasować. Dopóki router nie przepuści protokołu 47 i nie powiąże go z tym samym połączeniem, tunel nie może się rozpocząć. Poniższe sekcje rozdzielają dwa kanały, a następnie testują je po kolei.

Tabela portów nie ma wiersza dla numeru protokołu

PPTP używa dwóch rozmów, które zawodzą na różne sposoby. Ta na TCP 1723 rozpoczyna połączenie, przekazuje informacje o łączu i kończy je, gdy użytkownik się rozłącza. Strona ładunku działa wewnątrz GRE, który nagłówek IP oznacza numerem protokołu 47, a w tym tunelu PPP negocjuje łącze, podczas gdy MS-CHAPv2 sprawdza poświadczenia.

Ponieważ GRE nie niesie nagłówka transportowego, nie udostępnia żadnych portów, więc reguła napisana dla portów nie ma czego dopasować. Router przekierowujący 1723 tworzy mapowanie dla tej sesji TCP i na tym poprzestaje. Firmware obsługujący drugą połowę nazywa tę funkcję przepuszczaniem PPTP lub PPTP ALG, a niektóre firmware nie oferują żadnej z nich i nigdy nie wspominają o tej luce. Etykieta na polu wyboru ma mniejsze znaczenie niż to, czy protokół 47 jest w ogóle rozpoznawany.

Co zgłasza Windows, gdy ścieżka danych umiera

Błąd 807 mówi, że nie udało się nawiązać połączenia, co w praktyce oznacza, że połączenie dotarło do serwera, a kanał danych nie wstał. To wyrok o transporcie, nie o koncie. Błąd 691 to ten, który wskazuje na poświadczenia lub na niezgodność protokołu uwierzytelniania, więc wysyła cię zupełnie gdzie indziej.

Pracuj nad transportem, zanim dotkniesz hasła. Zmiana poświadczeń w pogoni za 807 zostawia prawdziwą usterkę na miejscu i utrudnia odczytanie kolejnej próby.

Dlaczego drugi klient psuje działający tunel

Bez portów, które by je rozróżniały, urządzenie NAT nie potrafi rozdzielić dwóch klientów PPTP tak, jak rozdziela dwie sesje HTTPS. Dlatego wiele urządzeń konsumenckich pozwala na jedno połączenie PPTP i śledzi je po adresie źródłowym. Laptop, który działał sam, przestaje kończyć połączenie, gdy druga maszyna wybierze numer, a z perspektywy klienta awaria wygląda losowo. Ten wzorzec należy do firmware i żadna zmiana profilu go nie zmieni.

Obserwuj tabelę połączeń, gdy oba klienty wybierają numer. Jeśli mapowanie zawsze trzyma tylko pierwszy host, router osiągnął granicę tego, co obsługuje, i żadne ustawienie po stronie klienta tego nie ruszy.

Udowodnij, która połowa zawodzi

Przed zmianą czegokolwiek na routerze potwierdź, że TCP 1723 dochodzi, bo ta odpowiedź decyduje, którą połowę testujesz. Uruchom te polecenia z klienta Windows wobec własnej nazwy serwera. Pierwsze wypisuje, czy port odpowiedział, a drugie wybiera numer bez okna dialogowego, co czyni powtarzane próby porównywalnymi.

Test-NetConnection vpn.example.com -Port 1723
rasdial "Work VPN"

Prawdziwy wynik testu portu oznacza, że kanał kontrolny jest otwarty i że GRE jest pozostałym podejrzanym. Fałszywy wynik oznacza, że routing, filtr lub przekierowanie są zepsute, i żadna zmiana GRE tego nie uratuje. Strony danych trzeba pilnować tam, gdzie jest widoczna, na serwerze lub na routerze.

tcpdump -ni any proto 47

Odpowiednikiem w Wiresharku jest filtr wyświetlania ip proto 47, który łatwiej przekazać komuś, kto nie czuje się swobodnie w wierszu poleceń. GRE, które przychodzi bez niczego wychodzącego w odpowiedzi, oznacza, że trzeba naprawić drogę powrotną.

Co naprawdę naprawia błąd

Tam, gdzie router udostępnia ustawienie, włącz przepuszczanie PPTP lub zezwól jawnie na protokół 47 w firmware, które przyjmuje reguły. W RouterOS reguła przekierowania dopasowuje protokół bezpośrednio, czego przekierowanie oparte na portach nigdy by nie potrafiło. Firmware konsumencki zwykle ukrywa tę samą decyzję za polem wyboru, czasem w ustawieniach bezpieczeństwa, a nie w przekierowaniu portów. Jeśli takie sterowanie nie istnieje, nic po stronie klienta tego nie zrekompensuje.

/ip firewall filter add chain=forward protocol=gre action=accept
/ip firewall filter print where protocol=gre

Zastąpienie PPTP jest drugą opcją i często tańszą. Router, który sam kończy VPN, unika podwójnego NAT dla klientów przychodzących, a protokół, który NAT oparty na portach już obsługuje, w ogóle nie potrzebuje przepuszczania: OpenVPN przez UDP, SSTP przez TCP 443 lub L2TP/IPsec z NAT-T, który pakuje ESP w UDP 4500. PPTP zależy też od MS-CHAPv2, którego udokumentowane słabości czynią go złym wyborem do nowego wdrożenia nawet po ustąpieniu błędu.

Zapisz, która reguła zrobiła różnicę, bo ta sama lokalizacja napotka ten sam limit, gdy drugi użytkownik poprosi o dostęp. Poprawka na poziomie protokołu należy do notatek sieciowych, gdzie zajrzy następny inżynier.