PPTP-passthrough mangler: ret Windows VPN-fejl 807

Videresendelse af TCP 1723 åbner ofte den første del af PPTP og efterlader resten brudt, så Windows stadig returnerer fejl 807 ved forsøget. Den næste indskydelse er at tilføje en regel for port 47, og netop det trin koster en eftermiddag: GRE er et protokolnnummer i IP-headeren, ikke en port som en videresendelsestabel kan matche. Indtil routeren sender protokol 47 videre og binder den til det samme opkald, kan tunnelen ikke starte. Afsnittene nedenfor adskiller de to kanaler og tester dem derefter én ad gangen.

En porttabel har ingen række til et protokolnnummer

PPTP bruger to samtaler, som fejler på forskellige måder. Den på TCP 1723 starter opkaldet, sender linkoplysninger og river det ned, når brugeren afbryder. Nyttelastssiden kører inde i GRE, som IP-headeren mærker med protokolnnummer 47, og inde i den tunnel forhandler PPP linket, mens MS-CHAPv2 kontrollerer legitimationsoplysningerne.

Fordi GRE ikke bærer nogen transportheader, viser den ingen porte, så en regel skrevet til porte har intet at matche. En router, der videresender 1723, opretter en mapping til den TCP-session og stopper der. Firmware, der håndterer den anden halvdel, kalder funktionen PPTP-passthrough eller en PPTP-ALG, og noget firmware tilbyder ingen af delene og nævner aldrig hullet. Etiketten på afkrydsningsfeltet betyder mindre end, hvorvidt protokol 47 overhovedet genkendes.

Hvad Windows rapporterer, når datastien dør

Fejl 807 siger, at forbindelsen ikke kunne fuldføres, hvilket i praksis betyder, at opkaldet nåede serveren, og at datakanalen ikke kom op. Det er en dom over transporten, ikke en dom over kontoen. Fejl 691 er den, der peger på legitimationsoplysninger eller på uoverensstemmelse i godkendelsesprotokollen, så den sender dig et helt andet sted hen.

Arbejd på transporten, før du rører adgangskoden. At ændre legitimationsoplysninger for at jage 807 lader den egentlige fejl blive på plads og gør det næste forsøg sværere at læse.

Hvorfor en anden klient bryder en tunnel, der virker

Uden porte, der kan skelne dem, kan en NAT-enhed ikke adskille to PPTP-klienter, som den adskiller to HTTPS-sessioner. Derfor tillader mange forbrugerenheder ét PPTP-opkald og følger det via kildeadressen. En bærbar computer, der virkede alene, holder op med at fuldføre, når en anden maskine ringer ud, og fra klientsiden ser fejlen tilfældig ud. Det mønster hører til firmwaren, og ingen profilændring vil ændre det.

Overvåg forbindelsestabellen, mens begge klienter ringer op. Hvis kun den første vært nogensinde har en mapping, har routeren nået grænsen for, hvad den understøtter, og ingen indstilling på klientsiden flytter det.

Bevis, hvilken halvdel der svigter

Bekræft, at TCP 1723 ankommer, før du ændrer noget på routeren, fordi det svar afgør, hvilken halvdel du tester. Kør disse fra Windows-klienten mod dit eget servernavn. Den første udskriver, om porten svarede, og den anden ringer op uden dialog, hvilket gør gentagne forsøg sammenlignelige.

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

Et sandt resultat i porttesten betyder, at kontrolkanalen er åben, og at GRE er den resterende mistænkte. Et falsk resultat betyder, at routing, et filter eller videresendelsen er brudt, og ingen GRE-ændring redder det. Datasiden skal overvåges der, hvor den kan ses, på serveren eller på routeren.

tcpdump -ni any proto 47

Ækvivalenten i Wireshark er visningsfilteret ip proto 47, som er lettere at give videre til en, der ikke er tryg ved en kommandolinje. GRE, der ankommer uden noget i svaret, betyder, at returvejen skal rettes.

Hvad der faktisk retter fejlen

Hvor routeren viser indstillingen, skal du aktivere PPTP-passthrough eller tillade protokol 47 eksplicit på firmware, der accepterer regler. På RouterOS matcher videresendelsesreglen protokollen direkte, hvilket en portbaseret videresendelse aldrig kunne. Forbrugerfirmware skjuler normalt den samme beslutning bag et afkrydsningsfelt, nogle gange under sikkerhedsindstillinger i stedet for under portvideresendelse. Hvis der ikke findes en sådan kontrol, kompenserer intet på klienten for det.

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

At erstatte PPTP er den anden mulighed og ofte den billigere. En router, der selv afslutter VPN, undgår dobbelt NAT for indgående klienter, og en protokol, som en portbaseret NAT allerede håndterer, kræver slet ingen passthrough: OpenVPN over UDP, SSTP over TCP 443 eller L2TP/IPsec med NAT-T, der pakker ESP ind i UDP 4500. PPTP afhænger også af MS-CHAPv2, hvis dokumenterede svagheder gør det til et dårligt valg til en ny udrulning, selv efter fejlen er væk.

Skriv ned, hvilken regel der gjorde forskellen, for det samme sted vil møde den samme grænse, når den anden bruger beder om adgang. En rettelse på protokolniveau hører i netværksnoterne, hvor den næste ingeniør vil kigge.