Lipsește passthrough-ul PPTP: repară eroarea 807 din Windows VPN

Redirecționarea TCP 1723 deschide adesea prima parte a PPTP și lasă restul stricat, așa că Windows tot returnează eroarea 807 la încercare. Următorul impuls este să adaugi o regulă pentru portul 47, și exact acel pas irosește o după-amiază: GRE este un număr de protocol în antetul IP, nu un port pe care un tabel de redirecționare îl poate potrivi. Până când routerul nu lasă protocolul 47 să treacă și nu îl leagă de același apel, tunelul nu poate porni. Secțiunile de mai jos separă cele două canale și apoi le testează unul câte unul.

Un tabel de porturi nu are rând pentru un număr de protocol

PPTP folosește două conversații care eșuează în moduri diferite. Cea de pe TCP 1723 începe apelul, transmite informațiile legăturii și îl închide când utilizatorul se deconectează. Partea de încărcare rulează în interiorul GRE, pe care antetul IP îl marchează cu numărul de protocol 47, iar în acel tunel PPP negociază legătura în timp ce MS-CHAPv2 verifică acreditările.

Deoarece GRE nu poartă niciun antet de transport, nu expune niciun port, așa că o regulă scrisă pentru porturi nu are ce potrivi. Un router care redirecționează 1723 creează o mapare pentru acea sesiune TCP și se oprește acolo. Firmware-ul care se ocupă de a doua jumătate numește funcția passthrough PPTP sau PPTP ALG, iar unele firmware-uri nu oferă niciuna și nu menționează niciodată golul. Eticheta de pe casetă contează mai puțin decât dacă protocolul 47 este recunoscut deloc.

Ce raportează Windows când calea de date moare

Eroarea 807 spune că conexiunea nu a putut fi finalizată, ceea ce în practică înseamnă că apelul a ajuns la server, iar canalul de date nu s-a ridicat. Este o sentință despre transport, nu despre cont. Eroarea 691 este cea care indică acreditările sau o nepotrivire a protocolului de autentificare, așa că te trimite cu totul altundeva.

Lucrează la transport înainte de a atinge parola. Schimbarea acreditărilor pentru a urmări 807 lasă defectul real la locul lui și face următoarea încercare mai greu de citit.

De ce un al doilea client strică un tunel care funcționează

Fără porturi care să le distingă, un dispozitiv NAT nu poate separa doi clienți PPTP așa cum separă două sesiuni HTTPS. De aceea multe echipamente de consum permit un singur apel PPTP și îl urmăresc după adresa sursă. Un laptop care funcționa singur nu mai finalizează imediat ce o a doua mașină formează numărul, iar din partea clientului defecțiunea pare aleatoare. Acel tipar aparține firmware-ului, iar nicio schimbare de profil nu îl va modifica.

Urmărește tabelul de conexiuni în timp ce ambii clienți formează numărul. Dacă doar primul host deține vreodată o mapare, routerul a atins limita a ceea ce acceptă și nicio setare din partea clientului nu îl va mișca.

Demonstrează care jumătate eșuează

Confirmă că TCP 1723 ajunge înainte de a schimba ceva pe router, pentru că acel răspuns decide care jumătate o testezi. Rulează acestea din clientul Windows împotriva propriului nume de server. Prima tipărește dacă portul a răspuns, iar a doua formează numărul fără dialog, ceea ce face încercările repetate comparabile.

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

Un rezultat adevărat la testul portului înseamnă că canalul de control este deschis și că GRE este suspectul rămas. Un rezultat fals înseamnă că rutarea, un filtru sau redirecționarea sunt stricate, și nicio modificare a GRE nu va salva asta. Partea de date trebuie urmărită acolo unde se vede, la server sau la router.

tcpdump -ni any proto 47

Echivalentul în Wireshark este filtrul de afișare ip proto 47, care este mai ușor de dat cuiva care nu se simte confortabil pe o linie de comandă. Un GRE care ajunge fără ca nimic să iasă în răspuns înseamnă că ruta de întoarcere trebuie reparată.

Ce repară de fapt eroarea

Acolo unde routerul expune setarea, activează passthrough-ul PPTP sau permite explicit protocolul 47 pe firmware care acceptă reguli. Pe RouterOS regula de redirecționare potrivește protocolul direct, ceea ce o redirecționare bazată pe porturi nu ar fi putut face niciodată. Firmware-ul de consum ascunde de obicei aceeași decizie în spatele unei casete, uneori în setările de securitate și nu în redirecționarea porturilor. Dacă nu există un astfel de control, nimic din partea clientului nu îl compensează.

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

Înlocuirea PPTP este cealaltă opțiune și adesea cea mai ieftină. Un router care termină el însuși VPN-ul evită NAT dublu pentru clienții care sosesc, iar un protocol pe care un NAT bazat pe porturi îl tratează deja nu are nevoie deloc de passthrough: OpenVPN pe UDP, SSTP pe TCP 443 sau L2TP/IPsec cu NAT-T care învelește ESP în UDP 4500. PPTP depinde și de MS-CHAPv2, ale cărui slăbiciuni documentate îl fac o alegere proastă pentru o implementare nouă chiar și după ce eroarea dispare.

Notează ce regulă a făcut diferența, pentru că același sit va întâlni aceeași limită atunci când al doilea utilizator va cere acces. O corecție la nivel de protocol aparține notelor de rețea, unde se va uita următorul inginer.