PPTP-fel 800 mot 812 och avbrott efter en minut

Tre felmeddelanden från en och samma PPTP-klient beskriver oftast tre olika fel. Fel 800 betyder att tunneln aldrig bildades, fel 812 betyder att servern avvisade autentiseringsmetoden, och ett avbrott efter en minut är en keepalive-timer som avgör att en frisk peer är borta. Varje steg misslyckas av sin egen anledning, så varje steg behöver sin egen kontroll.

Fel 800 betyder att tunneln aldrig bildades

Windows visar fel 800 när det inte alls kan bygga tunneln, och texten om en oåtkomlig server eller olämpliga säkerhetsparametrar är en sammanfattning och inte en diagnos. PPTP behöver två separata saker från nätverket innan någon inloggningsuppgift granskas. TCP 1723 bär kontrollkanalen, och IP-protokoll 47, GRE, bär den inkapslade lasten.

Testa den yttre vägen utanför ditt eget LAN, för en anslutning som fungerar på kontoret bevisar ingenting om kanten:

$ nc -vz vpn.example.net 1723
Connection to vpn.example.net 1723 port [tcp/*] succeeded!
$ sudo tcpdump -ni eth0 proto gre
tcpdump: listening on eth0, link-type EN10MB

Om 1723 svarar och fångsten förblir tom medan klienten försöker ansluta, släpper vägen protokoll 47. En router med 1723 vidarebefordrat men PPTP-passthrough avstängt ger exakt det mönstret: TCP-handskakningen fullbordas, sedan försvinner GRE-paketen, så felet ser ut som ett inloggningsproblem trots att ingen inloggning försökts.

Rikta vidarebefordran mot serverns nuvarande LAN-adress, slå på PPTP-passthrough där routern erbjuder det, och försök igen från samma yttre punkt. När GRE filtreras längre upp och du inte kan ändra det, har SSTP över TCP 443 eller L2TP/IPsec över UDP 500 och 4500 bättre chans än någon ändring du kan göra på Windows-sidan.

Fel 812 är servern som avvisar din autentiseringsmetod

Fel 812 kommer tillbaka efter att tunneln är uppe, därför känns det som ett lösenordsproblem. Servern avvisar autentiseringsmetoden som förhandlades fram för anslutningen, inte nödvändigtvis själva lösenordet. På klienten, öppna VPN-posten, gå till fliken säkerhet, ställ in typen på Point-to-Point Tunneling Protocol, välj den uttryckliga protokolllistan och kryssa för Microsoft CHAP version 2.

Du kan läsa den aktuella inställningen utan att klicka genom dialogrutan:

$ Get-VpnConnection -Name "Office" | Select-Object -ExpandProperty AuthenticationMethod
MsChapv2

En server som kräver MS-CHAP v2 avvisar en klient som lämnats på PAP eller på en automatisk typ som förhandlar om något svagare, och felet kommer innan något användarlösenord utvärderas. Kontoformatet är den andra hälften av samma avvisande. I ett fall skickade Windows en Microsoft-kontoidentitet av formen MicrosoftAccount\[email protected] medan servern ville ha ett lokalt eller domänkonto. Att skriva SERVERNAME\username talade om för Windows vilket kontolager som skulle användas och tog bort felet. Skriv in namnet för hand i stället för att låta en sparad inloggningsuppgift upprepa ett tidigare format.

Avbrott efter en minut är ett keepalive-beslut

När tunneln ansluter, släpper igenom lite trafik och sedan kopplar från, titta på serverns LCP-ekobeteende innan du rör klienten. Daemonen ber peeraren med jämna mellanrum bekräfta att den fortfarande är där. Om det kommer för få svar inom den konfigurerade budgeten rivs sessionen trots att användaren fortfarande har en fungerande länk.

På en Linux pptpd-server bor dessa värden i /etc/ppp/options.pptpd, och den vanliga reparationen är att vidga budgeten i stället för att korta intervallet:

# /etc/ppp/options.pptpd
lcp-echo-failure 30
lcp-echo-interval 5
# then
sudo systemctl restart pptpd

Trettio missar vid ett intervall på fem sekunder förlåter en kort paus i stället för att förklara peeraren borta. Att sänka antalet till ett eller två gör vanlig jitter på en översatt väg till en frånkoppling ungefär varje minut. Om din server är Windows RRAS och inte pptpd, titta i stället på PPP-sessionens tidsgräns och policyn för frånkoppling vid inaktivitet. De bor någon annanstans, och att redigera en pppd-fil som inte finns ändrar ingenting.

Överlappande subnät bryter datavägen

En PPTP-tunnel kan autentisera rent och ändå inte nå något när båda platserna använder samma privata intervall, till exempel 192.168.1.0/24 på kontoret och hemma. Klienten kan inte säga vilken värd en viss adress avser, och vissa stackar vägrar installera rutten alls i stället för att välja en.

Behandla det som ett designfel och numrera om ena sidan, eller ge klienten ett medvetet översatt åtkomstintervall. Felsökning av PPTP-klienten kan inte reparera ett adressutrymme som finns två gånger, och symptomet kommer att fortsätta se ut som ett slumpmässigt avbrott.

Börja med steget som misslyckades: GRE för 800, metoden och kontosträngen för 812, ekoinställningar för en tunnel som dör enligt schemat.