PPTP-fejl 800 kontra 812 og forbindelser, der falder efter et minut

Tre fejlmeddelelser fra én PPTP-klient beskriver normalt tre forskellige fejl. Fejl 800 betyder, at tunnelen aldrig blev dannet, fejl 812 betyder, at serveren afviste godkendelsesmetoden, og et forbindelsestab efter et minut er en keepalive-timer, der beslutter, at en sund partner er væk. Hvert trin fejler af sin egen grund, så hvert trin kræver sit eget tjek.

Fejl 800 betyder, at tunnelen aldrig blev dannet

Windows rejser fejl 800, når det slet ikke kan bygge tunnelen, og teksten om en utilgængelig server eller uegnede sikkerhedsparametre er et resumé og ikke en diagnose. PPTP har brug for to separate ting fra netværket, før nogen legitimationsoplysning undersøges. TCP 1723 bærer kontrolkanalen, og IP-protokol 47, GRE, bærer den indkapslede last.

Test den ydre vej udefra dit eget LAN, fordi en forbindelse, der virker på kontoret, ikke beviser noget 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 optagelsen forbliver tom, mens klienten forsøger at forbinde, dropper vejen protokol 47. En router med 1723 videresendt, men PPTP-passthrough slået fra giver præcis det mønster: TCP-håndtrykket fuldføres, derefter forsvinder GRE-pakkerne, så fejlen ligner et problem med legitimationsoplysninger, selv om der ikke blev forsøgt noget login.

Ret videresendelsen mod serverens aktuelle LAN-adresse, slå PPTP-passthrough til, hvor routeren tilbyder det, og prøv igen fra samme ydre sted. Når GRE filtreres længere oppe og du ikke kan ændre det, har SSTP over TCP 443 eller L2TP/IPsec over UDP 500 og 4500 en bedre chance end nogen ændring, du kan lave på Windows-siden.

Fejl 812 er serveren, der afviser din godkendelsesmetode

Fejl 812 kommer tilbage, efter at tunnelen er oppe, og derfor føles den som et adgangskodeproblem. Serveren afviser den godkendelsesmetode, der blev forhandlet til forbindelsen, ikke nødvendigvis selve adgangskoden. På klienten skal du åbne VPN-posten, gå til sikkerhedsfanen, sætte typen til Point-to-Point Tunneling Protocol, vælge den eksplicitte protokol liste og sætte kryds ved Microsoft CHAP version 2.

Du kan læse den aktuelle indstilling uden at klikke gennem dialogen:

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

En server, der kræver MS-CHAP v2, afviser en klient, der er efterladt på PAP eller på en automatisk type, der forhandler noget svagere, og fejlen kommer, før nogen brugeradgangskode vurderes. Kontoformatet er den anden halvdel af samme afvisning. I et tilfælde sendte Windows en Microsoft-kontoidentitet af formen MicrosoftAccount\[email protected], mens serveren ville have en lokal eller domænekonto. At skrive SERVERNAME\username fortalte Windows, hvilket kontolager der skulle slås op, og fjernede fejlen. Indtast navnet manuelt i stedet for at lade en gemt legitimationsoplysning gentage et tidligere format.

Forbindelsestab efter et minut er en keepalive-beslutning

Når tunnelen forbinder, sender lidt trafik og derefter afbryder, skal du se på serverens LCP-ekkoadfærd, før du rører klienten. Dæmonen beder jævnligt partneren om at bekræfte, at den stadig er der. Hvis der kommer for få svar inden for det konfigurerede budget, rives sessionen ned, selv om brugeren stadig har et fungerende link.

På en Linux pptpd-server bor disse værdier i /etc/ppp/options.pptpd, og den sædvanlige reparation er at udvide budgettet i stedet for at forkorte intervallet:

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

Tredive misses ved et interval på fem sekunder tilgiver en kort pause i stedet for at erklære partneren væk. At skrue antallet ned til en eller to gør almindeligt jitter på en oversat vej til en afbrydelse omtrent hvert minut. Hvis din server er Windows RRAS i stedet for pptpd, skal du i stedet se på PPP-sessionens timeout og politikken for afbrydelse ved inaktivitet. De bor et andet sted, og at redigere en pppd-fil, der ikke findes, ændrer intet.

Overlappende undernet ødelægger datastien

En PPTP-tunnel kan godkende rent og stadig ikke nå noget, når begge steder bruger samme private område, for eksempel 192.168.1.0/24 på kontoret og derhjemme. Klienten kan ikke se, hvilken vært en given adresse henviser til, og nogle stakke nægter helt at installere ruten i stedet for at vælge en.

Behandl det som en designfejl, og omnummerér den ene side, eller giv klienten et bevidst oversat adgangsområde. Fejlsøgning i PPTP-klienten kan ikke rette et adresserum, der findes to gange, og symptomet vil fortsat ligne et tilfældigt tab.

Start med det trin, der svigtede: GRE for 800, metoden og kontostrengen for 812, ekkoindstillinger for en tunnel, der dør efter planen.