PPTP-fout 800 tegenover 812 en verbindingen die na een minuut wegvallen

Fout 800, fout 812 en een PPTP-tunnel die na een minuut sterft, zijn drie verschillende storingen. Koppel elk symptoom aan de laag die werkelijk faalde.

Drie foutmeldingen van één PPTP-client beschrijven meestal drie verschillende storingen. Fout 800 betekent dat de tunnel nooit tot stand kwam, fout 812 betekent dat de server de authenticatiemethode weigerde, en een onderbreking na een minuut is een keepalive-timer die besluit dat een gezonde peer weg is. Elke fase faalt om zijn eigen reden, dus elke fase heeft zijn eigen controle nodig.

Fout 800 betekent dat de tunnel nooit tot stand kwam

Windows meldt fout 800 wanneer het de tunnel helemaal niet kan opbouwen, en de tekst over een onbereikbare server of ongeschikte beveiligingsparameters is een samenvatting en geen diagnose. PPTP heeft twee afzonderlijke dingen van het netwerk nodig voordat er ook maar een inloggegeven wordt bekeken. TCP 1723 draagt het besturingskanaal, en IP-protocol 47, GRE, draagt de ingekapselde lading.

Test dat buitenpad van buiten je eigen LAN, want een verbinding die op kantoor werkt, bewijst niets over de rand:

$ 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

Als 1723 antwoordt en de opname leeg blijft terwijl de client probeert te verbinden, laat het pad protocol 47 vallen. Een router met 1723 doorgestuurd maar PPTP-passthrough uitgeschakeld levert precies dat patroon: de TCP-handshake voltooit, daarna verdwijnen de GRE-pakketten, zodat de fout op een inloggegevenprobleem lijkt terwijl er geen aanmelding is geprobeerd.

Richt de doorsturing op het huidige LAN-adres van de server, zet PPTP-passthrough aan waar de router het biedt, en probeer opnieuw vanaf hetzelfde buitenpunt. Wanneer GRE stroomopwaarts wordt gefilterd en je dat niet kunt wijzigen, heeft SSTP over TCP 443 of L2TP/IPsec over UDP 500 en 4500 meer kans dan welke wijziging dan ook aan de Windows-kant.

Fout 812 is de server die je authenticatiemethode weigert

Fout 812 komt terug nadat de tunnel staat, daarom voelt het als een wachtwoordprobleem. De server weigert de voor de verbinding onderhandelde authenticatiemethode, niet noodzakelijk het wachtwoord zelf. Open op de client de VPN-vermelding, ga naar het tabblad beveiliging, zet het type op Point-to-Point Tunneling Protocol, kies de expliciete protocollijst en vink Microsoft CHAP versie 2 aan.

Je kunt de huidige instelling lezen zonder door de dialoog te klikken:

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

Een server die MS-CHAP v2 vereist, weigert een client die op PAP of op een automatisch type is gelaten dat iets zwakkers onderhandelt, en de fout komt voordat er enig gebruikerswachtwoord wordt beoordeeld. Het accountformaat is de andere helft van dezelfde weigering. In één geval stuurde Windows een Microsoft-accountidentiteit van de vorm MicrosoftAccount\[email protected] terwijl de server een lokaal of domeinaccount wilde. SERVERNAME\username typen vertelde Windows welk accountarchief te raadplegen en haalde de fout weg. Voer de naam met de hand in in plaats van een opgeslagen inloggegeven een eerder formaat te laten herhalen.

Onderbrekingen na een minuut zijn een keepalive-beslissing

Wanneer de tunnel verbindt, wat verkeer doorlaat en daarna loskoppelt, kijk dan naar het LCP-echogedrag van de server voordat je de client aanraakt. De daemon vraagt de peer regelmatig te bevestigen dat hij er nog is. Als er te weinig antwoorden binnen het ingestelde budget komen, wordt de sessie afgebroken ook al heeft de gebruiker nog een werkende verbinding.

Op een Linux pptpd-server wonen die waarden in /etc/ppp/options.pptpd, en de gebruikelijke reparatie is het budget te verbreden in plaats van het interval te verkorten:

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

Dertig gemiste antwoorden bij een interval van vijf seconden vergeven een korte hapering in plaats van de peer als weg te verklaren. Het aantal terugbrengen naar één of twee maakt gewone jitter op een vertaald pad tot een onderbreking ongeveer elke minuut. Is je server Windows RRAS en niet pptpd, kijk dan in plaats daarvan naar de PPP-sessietime-out en het beleid voor loskoppelen bij inactiviteit. Die wonen ergens anders, en een pppd-bestand bewerken dat niet bestaat verandert niets.

Overlappende subnetten breken het datapad

Een PPTP-tunnel kan schoon authenticeren en toch niets bereiken wanneer beide locaties dezelfde privéreeks gebruiken, bijvoorbeeld 192.168.1.0/24 op kantoor en thuis. De client kan niet zeggen op welke host een bepaald adres doelt, en sommige stacks weigeren de route helemaal te installeren in plaats van er één te kiezen.

Behandel dat als een ontwerpfout en hernummer één kant, of geef de client een bewust vertaald toegangsbereik. Foutopsporing in de PPTP-client kan geen adresruimte repareren die twee keer bestaat, en het symptoom zal blijven lijken op een willekeurige onderbreking.

Begin bij de fase die faalde: GRE voor 800, de methode en accountstring voor 812, echo-instellingen voor een tunnel die volgens schema sterft.

Gerelateerde artikelen