PPTP-passthrough manglar: rett opp Windows VPN-feil 807

Vidaresending av TCP 1723 opnar ofte den første delen av PPTP og lèt resten vere øydelagd, så Windows returnerer framleis feil 807 ved forsøket. Den neste innskota er å leggje til ein regel for port 47, og nett det steget kostar ein ettermiddag: GRE er eit protokollnummer i IP-headeren, ikkje ein port som ein vidaresendingstabell kan matche. Før rutaren slepp protokoll 47 gjennom og bind han til same anropet, kan tunnelen ikkje starte. Avsnitta nedanfor skil dei to kanalane og testar dei deretter ein om gongen.

Ein porttabell har inga rad for eit protokollnummer

PPTP brukar to samtalar som feilar på ulike måtar. Den på TCP 1723 startar anropet, sender lenkjeinformasjon og riv det ned når brukaren koplar frå. Nyttelastssida køyrer inne i GRE, som IP-headeren merkar med protokollnummer 47, og inne i den tunnelen forhandlar PPP lenkja medan MS-CHAPv2 kontrollerer påloggingsinformasjonen.

Sidan GRE ikkje ber nokon transportheader, viser han ingen portar, så ein regel skriven for portar har ingenting å matche. Ein rutar som vidaresender 1723 opprettar ein mapping for den TCP-økta og stoppar der. Fastvaren som handterer den andre halvdelen kallar funksjonen PPTP-passthrough eller PPTP ALG, og nokon fastvare tilbyr ingen av delane og nemner aldri gapet. Etiketten på avkrysningsboksen tyder mindre enn om protokoll 47 blir kjend att i det heile.

Kva Windows rapporterer når datastien døyr

Feil 807 seier at tilkoplinga ikkje kunne fullførast, noko som i praksis tyder at anropet nådde serveren og at datakanalen ikkje kom opp. Det er ei dom over transporten, ikkje over kontoen. Feil 691 er den som peikar på påloggingsinformasjon eller på eit mishøve i autentiseringsprotokollen, så han sender deg ein heilt annan stad.

Arbeid med transporten før du rører passordet. Å endre påloggingsinformasjon for å jage 807 lèt den eigentlege feilen bli ståande og gjer neste forsøk vanskelegare å lese.

Kvifor ein annan klient øydelegg ein tunnel som verkar

Utan portar som kan skilje dei, kan ein NAT-eining ikkje skilje to PPTP-klientar slik ho skil to HTTPS-økter. Derfor tillèt mange forbrukareiningar berre eitt PPTP-anrop og sporar det etter kjeldeadresse. Ein berbar PC som verka åleine sluttar å fullføre når ein andre maskin ringjer ut, og frå klientsida verkar feilen tilfeldig. Det mønsteret høyrer til fastvaren, og inga profilendring vil endre det.

Følg med på tilkoplingsstabellen medan begge klientane ringjer. Viss berre den første verten nokon gong har ein mapping, har rutaren nådd grensa for det han støttar, og inga innstilling på klientsida flyttar det.

Prov kva halvdel som sviktar

Stadfest at TCP 1723 kjem fram før du endrar noko på rutaren, fordi det svaret avgjer kva halvdel du testar. Køyr desse frå Windows-klienten mot ditt eige servernamn. Den første skriv ut om porten svara, og den andre ringjer ut utan dialog, noko som gjer gjentekne forsøk samanliknbare.

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

Eit sant resultat i porttesten tyder at kontrollkanalen er open og at GRE er den gjenverande mistenkte. Eit falskt resultat tyder at ruting, eit filter eller vidaresendinga er øydelagd, og inga GRE-endring reddar det. Datasida må overvakast der ho kan sjåast, på serveren eller på rutaren.

tcpdump -ni any proto 47

Motstykket i Wireshark er visingsfilteret ip proto 47, som er lettare å gje vidare til nokon som ikkje er komfortabel på ei kommandolinje. GRE som kjem inn utan at noko går ut i svar, tyder at returvegen må reparerast.

Kva som faktisk rettar feilen

Der rutaren viser innstillinga, aktiver PPTP-passthrough, eller tillat protokoll 47 eksplisitt på fastvare som godtek reglar. På RouterOS matchar vidaresendingsregelen protokollen direkte, noko ei portbasert vidaresending aldri kunne gjere. Forbrukarfastvare gøymer vanlegvis same avgjerd bak ein avkrysningsboks, stundom under tryggingsinnstillingar i staden for under portvidaresending. Viss inga slik kontroll finst, kompenserer ingenting på klienten for det.

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

Å erstatte PPTP er det andre alternativet og ofte det billegare. Ein rutar som sjølv avsluttar VPN-en unngår dobbel NAT for innkommande klientar, og ein protokoll som ein portbasert NAT allereie handterer, treng ingen passthrough i det heile: OpenVPN over UDP, SSTP over TCP 443 eller L2TP/IPsec med NAT-T som pakkar ESP inn i UDP 4500. PPTP er også avhengig av MS-CHAPv2, der dei dokumenterte svakheitene gjer det til eit dårleg val for ein ny utrulling sjølv etter at feilen er borte.

Skriv ned kva regel som gjorde skilnaden, for den same staden vil møte den same grensa når den andre brukaren ber om tilgang. Ei retting på protokollnivå høyrer i nettverksnotata, der den neste ingeniøren vil sjå.