PPTP-feil 800 mot 812 og forbindelser som faller etter et minutt

Tre feilmeldinger fra én PPTP-klient beskriver vanligvis tre forskjellige feil. Feil 800 betyr at tunnelen aldri ble dannet, feil 812 betyr at serveren avviste autentiseringsmetoden, og et brudd etter et minutt er en keepalive-timer som bestemmer at en sunn partner er borte. Hvert trinn feiler av sin egen grunn, så hvert trinn trenger sin egen kontroll.

Feil 800 betyr at tunnelen aldri ble dannet

Windows reiser feil 800 når det ikke kan bygge tunnelen i det hele tatt, og teksten om en utilgjengelig server eller uegnede sikkerhetsparametere er et sammendrag og ikke en diagnose. PPTP trenger to separate ting fra nettverket før noen legitimasjon undersøkes. TCP 1723 bærer kontrollkanalen, og IP-protokoll 47, GRE, bærer den innkapslede lasten.

Test den ytre veien utenfra ditt eget LAN, fordi en forbindelse som virker på kontoret ikke beviser noe 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

Hvis 1723 svarer og opptaket blir tomt mens klienten prøver å koble til, slipper veien protokoll 47. En ruter med 1723 videresendt, men PPTP-passthrough slått av gir akkurat det mønsteret: TCP-håndtrykket fullføres, deretter forsvinner GRE-pakkene, så feilen ser ut som et legitimasjonsproblem selv om ingen innlogging ble forsøkt.

Ret videresendingen mot serverens nåværende LAN-adresse, slå på PPTP-passthrough der ruteren tilbyr det, og prøv igjen fra samme ytre punkt. Når GRE filtreres lenger oppe og du ikke kan endre det, har SSTP over TCP 443 eller L2TP/IPsec over UDP 500 og 4500 bedre sjanse enn noen endring du kan gjøre på Windows-siden.

Feil 812 er serveren som avviser autentiseringsmetoden din

Feil 812 kommer tilbake etter at tunnelen er oppe, derfor føles den som et passordproblem. Serveren avviser autentiseringsmetoden som ble forhandlet for forbindelsen, ikke nødvendigvis selve passordet. På klienten, åpne VPN-oppføringen, gå til sikkerhetsfanen, sett typen til Point-to-Point Tunneling Protocol, velg den eksplisitte protokolllisten og kryss av for Microsoft CHAP versjon 2.

Du kan lese gjeldende innstilling uten å klikke deg gjennom dialogen:

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

En server som krever MS-CHAP v2, avviser en klient som er latt stå på PAP eller på en automatisk type som forhandler om noe svakere, og feilen kommer før noe brukerpassord vurderes. Kontoformatet er den andre halvdelen av den samme avvisningen. I ett tilfelle sendte Windows en Microsoft-kontoidentitet av formen MicrosoftAccount\[email protected] mens serveren ville ha en lokal eller domenekonto. Å skrive SERVERNAME\username fortalte Windows hvilket kontolager som skulle slås opp, og fjernet feilen. Skriv inn navnet for hånd i stedet for å la en lagret legitimasjon gjenta et tidligere format.

Brudd etter et minutt er en keepalive-beslutning

Når tunnelen kobler til, slipper gjennom litt trafikk og deretter kobler fra, se på serverens LCP-ekkoadferd før du rører klienten. Daemonen ber jevnlig partneren bekrefte at den fortsatt er der. Hvis det kommer for få svar innenfor det konfigurerte budsjettet, rives økten ned selv om brukeren fortsatt har en fungerende lenke.

På en Linux pptpd-server bor disse verdiene i /etc/ppp/options.pptpd, og den vanlige reparasjonen er å utvide budsjettet i stedet for å forkorte intervallet:

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

Tretti bom på et intervall på fem sekunder tilgir en kort pause i stedet for å erklære partneren borte. Å skru ned antallet til én eller to gjør vanlig jitter på en oversatt vei til en frakobling omtrent hvert minutt. Hvis serveren din er Windows RRAS og ikke pptpd, se i stedet på PPP-øktens tidsavbrudd og retningslinjen for frakobling ved inaktivitet. De bor et annet sted, og å redigere en pppd-fil som ikke finnes endrer ingenting.

Overlappende subnett ødelegger datastien

En PPTP-tunnel kan autentisere rent og likevel ikke nå noe når begge steder bruker samme private område, for eksempel 192.168.1.0/24 på kontoret og hjemme. Klienten kan ikke si hvilken vert en gitt adresse viser til, og noen stakker nekter å installere ruten i det hele tatt i stedet for å velge én.

Behandle det som en designfeil og omnummerer den ene siden, eller gi klienten et bevisst oversatt tilgangsområde. Feilsøking av PPTP-klienten kan ikke reparere et adresserom som finnes to ganger, og symptomet vil fortsatt se ut som et tilfeldig brudd.

Start med trinnet som sviktet: GRE for 800, metoden og kontostrengen for 812, ekkoinnstillinger for en tunnel som dør etter planen.