PPTP-passthrough saknas: åtgärda fel 807 i Windows VPN

Att vidarebefordra TCP 1723 rensar ofta den första delen av PPTP och lämnar resten trasig, så Windows returnerar fortfarande fel 807 vid försöket. Nästa instinkt är att lägga till en regel för port 47, och det är steget som slösar bort en eftermiddag: GRE är ett protokollnummer i IP-huvudet, inte en port som en vidarebefordringstabell kan matcha. Tills routern släpper igenom protokoll 47 och knyter det till samma anrop kan tunneln inte starta. Avsnitten nedan skiljer de två kanalerna åt och testar dem sedan en i taget.

En porttabell har ingen rad för ett protokollnummer

PPTP använder två konversationer som misslyckas på olika sätt. Den på TCP 1723 startar anropet, förmedlar länkinformation och river det när användaren kopplar från. Nyttosidan går inuti GRE, som IP-huvudet märker med protokollnummer 47, och inuti den tunneln förhandlar PPP länken medan MS-CHAPv2 kontrollerar inloggningsuppgifterna.

Eftersom GRE inte bär något transporthuvud exponerar det inga portar, så en regel skriven för portar har inget att matcha. En router som vidarebefordrar 1723 skapar en mappning för den TCP-sessionen och stannar där. Firmware som hanterar den andra halvan kallar funktionen PPTP-passthrough eller en PPTP-ALG, och viss firmware erbjuder ingendera och nämner aldrig gapet. Etiketten på kryssrutan spelar mindre roll än om protokoll 47 alls känns igen.

Vad Windows rapporterar när datavägen dör

Fel 807 säger att anslutningen inte kunde slutföras, vilket i praktiken betyder att anropet nådde servern och att datakanalen inte kom upp. Det är en dom om transporten, inte om kontot. Fel 691 är det som pekar på inloggningsuppgifter eller på en missanpassning av autentiseringsprotokollet, så det skickar dig någon helt annanstans.

Arbeta på transporten innan du rör lösenordet. Att ändra inloggningsuppgifter för att jaga 807 lämnar det verkliga felet på plats och gör nästa försök svårare att läsa.

Varför en andra klient bryter en fungerande tunnel

Utan portar att skilja dem åt kan en NAT-enhet inte separera två PPTP-klienter så som den separerar två HTTPS-sessioner. Många konsumentenheter tillåter därför ett PPTP-anrop och spårar det via källadress. En laptop som fungerade ensam slutar slutföra anslutningen när en andra maskin ringer ut, och från klientsidan ser felet slumpmässigt ut. Det mönstret tillhör firmware, och ingen profiländring förändrar det.

Titta på anslutningstabellen medan båda klienterna ringer. Om bara den första värden någonsin har en mappning har routern nått gränsen för vad den stöder och ingen inställning på klientsidan flyttar det.

Bevisa vilken halva som misslyckas

Bekräfta att TCP 1723 kommer fram innan du ändrar något på routern, eftersom det svaret avgör vilken halva du testar. Kör dem från Windows-klienten mot ditt eget servernamn. Den första skriver ut om porten svarade, och den andra ringer upp utan dialog, vilket gör upprepade försök jämförbara.

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

Ett sant resultat i porttestet betyder att kontrollkanalen är öppen och att GRE är den kvarvarande misstänkta. Ett falskt resultat betyder att routning, ett filter eller vidarebefordran är trasig, och ingen GRE-ändring räddar det. Datasidan måste övervakas där den kan ses, vid serveränden eller vid routern.

tcpdump -ni any proto 47

Motsvarigheten i Wireshark är visningsfiltret ip proto 47, vilket är lättare att lämna till någon som inte är bekväm i ett skal. GRE som anländer utan att något lämnar som svar betyder att returvägen behöver repareras.

Vad som faktiskt åtgärdar felet

Där routern exponerar inställningen, aktivera PPTP-passthrough, eller tillåt protokoll 47 uttryckligen på firmware som tar emot regler. På RouterOS matchar forward-regeln protokollet direkt, vilket en portbaserad vidarebefordran aldrig skulle kunna göra. Konsumentfirmware gömmer oftast samma beslut bakom en kryssruta, ibland under säkerhetsinställningar i stället för under portvidarebefordran. Om ingen sådan kontroll finns kompenserar ingenting på klienten.

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

Att ersätta PPTP är det andra alternativet och ofta det billigare. En router som själv avslutar VPN undviker dubbel NAT för inkommande klienter, och ett protokoll som en portbaserad NAT redan hanterar behöver ingen passthrough alls: OpenVPN över UDP, SSTP över TCP 443, eller L2TP/IPsec med NAT-T som lindar in ESP i UDP 4500. PPTP är också beroende av MS-CHAPv2, vars dokumenterade svagheter gör det till ett dåligt val för en ny driftsättning även efter att felet är borta.

Skriv ned vilken regel som gjorde skillnaden, eftersom samma plats möter samma gräns när den andra användaren begär åtkomst. En protokollnivåfix hör hemma i nätverksanteckningarna, där nästa ingenjör kommer att titta.