PPTP-passthrough mangler: fiks Windows VPN-feil 807

Videresending av TCP 1723 åpner ofte den første delen av PPTP og lar resten være ødelagt, så Windows returnerer fortsatt feil 807 ved forsøket. Den neste innskytelsen er å legge til en regel for port 47, og nettopp det trinnet koster en ettermiddag: GRE er et protokollnummer i IP-headeren, ikke en port som en videresendingstabell kan matche. Før ruteren slipper protokoll 47 gjennom og binder den til samme anrop, kan tunnelen ikke starte. Avsnittene nedenfor skiller de to kanalene og tester dem deretter én om gangen.

En porttabell har ingen rad for et protokollnummer

PPTP bruker to samtaler som feiler på ulike måter. Den på TCP 1723 starter anropet, sender lenkeinformasjon og river det ned når brukeren kobler fra. Nyttelastssiden kjører inne i GRE, som IP-headeren merker med protokollnummer 47, og inne i den tunnelen forhandler PPP lenken mens MS-CHAPv2 kontrollerer påloggingsinformasjonen.

Siden GRE ikke bærer noen transportheader, viser den ingen porter, så en regel skrevet for porter har ingenting å matche. En ruter som videresender 1723 oppretter en mapping for den TCP-økten og stopper der. Fastvaren som håndterer den andre halvdelen kaller funksjonen PPTP-passthrough eller PPTP ALG, og noen fastvare tilbyr ingen av delene og nevner aldri gapet. Etiketten på avkrysningsboksen betyr mindre enn hvorvidt protokoll 47 blir gjenkjent i det hele tatt.

Hva Windows rapporterer når datastien dør

Feil 807 sier at tilkoblingen ikke kunne fullføres, noe som i praksis betyr at anropet nådde serveren og at datakanalen ikke kom opp. Det er en dom over transporten, ikke over kontoen. Feil 691 er den som peker på påloggingsinformasjon eller på en mismatch i autentiseringsprotokollen, så den sender deg et helt annet sted.

Arbeid med transporten før du rører passordet. Å endre påloggingsinformasjon for å jage 807 lar den egentlige feilen bli stående og gjør neste forsøk vanskeligere å lese.

Hvorfor en annen klient ødelegger en tunnel som virker

Uten porter som kan skille dem, kan en NAT-enhet ikke skille to PPTP-klienter slik den skiller to HTTPS-økter. Derfor tillater mange forbrukerenheter bare ett PPTP-anrop og sporer det etter kildeadresse. En bærbar PC som virket alene slutter å fullføre når en andre maskin ringer ut, og fra klientsiden virker feilen tilfeldig. Det mønsteret tilhører fastvaren, og ingen profilendring vil endre det.

Følg med på tilkoblingstabellen mens begge klientene ringer. Hvis bare den første verten noen gang har en mapping, har ruteren nådd grensen for det den støtter, og ingen innstilling på klientsiden flytter det.

Bevis hvilken halvdel som svikter

Bekreft at TCP 1723 kommer fram før du endrer noe på ruteren, fordi det svaret avgjør hvilken halvdel du tester. Kjør disse fra Windows-klienten mot ditt eget servernavn. Den første skriver ut om porten svarte, og den andre ringer uten dialog, noe som gjør gjentatte forsøk sammenlignbare.

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

Et sant resultat i porttesten betyr at kontrollkanalen er åpen og at GRE er den gjenværende mistenkte. Et falskt resultat betyr at ruting, et filter eller videresendingen er ødelagt, og ingen GRE-endring redder det. Datasiden må overvåkes der den kan ses, på serveren eller på ruteren.

tcpdump -ni any proto 47

Motstykket i Wireshark er visningsfilteret ip proto 47, som er lettere å gi videre til noen som ikke er komfortabel på en kommandolinje. GRE som kommer inn uten at noe går ut i svar, betyr at returveien må repareres.

Hva som faktisk fikser feilen

Der ruteren viser innstillingen, aktiver PPTP-passthrough, eller tillat protokoll 47 eksplisitt på fastvare som aksepterer regler. På RouterOS matcher videresendingsregelen protokollen direkte, noe en portbasert videresending aldri kunne gjøre. Forbrukerfastvare skjuler vanligvis samme beslutning bak en avkrysningsboks, noen ganger under sikkerhetsinnstillinger i stedet for under portvideresending. Hvis ingen slik kontroll finnes, 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 billigere. En ruter som selv avslutter VPN-en unngår dobbel NAT for innkommende klienter, og en protokoll som en portbasert NAT allerede håndterer, trenger ingen passthrough i det hele tatt: OpenVPN over UDP, SSTP over TCP 443 eller L2TP/IPsec med NAT-T som pakker ESP inn i UDP 4500. PPTP er også avhengig av MS-CHAPv2, hvis dokumenterte svakheter gjør det til et dårlig valg for en ny utrulling selv etter at feilen er borte.

Skriv ned hvilken regel som gjorde forskjellen, for det samme stedet vil møte den samme grensen når den andre brukeren ber om tilgang. En rettelse på protokollnivå hører i nettverksnotatene, der den neste ingeniøren vil se.