Error PPTP 800 davant de 812 i talls després d’un minut

Tres missatges de fallada d’un client PPTP solen descriure tres avaries diferents. L’error 800 vol dir que el túnel no es va arribar a formar mai, l’error 812 vol dir que el servidor va rebutjar el mètode d’autenticació, i un tall després d’un minut és un temporitzador de keepalive que decideix que un parell sa ha desaparegut. Cada etapa falla per la seva pròpia raó, així que cadascuna necessita la seva pròpia comprovació.

L’error 800 vol dir que el túnel no es va arribar a formar mai

Windows genera l’error 800 quan no pot construir el túnel de cap manera, i el text sobre un servidor inabastable o paràmetres de seguretat inadequats és un resum i no un diagnòstic. PPTP necessita dues coses separades de la xarxa abans que s’examini cap credencial. TCP 1723 porta el canal de control, i el protocol IP 47, GRE, porta la càrrega encapsulada.

Prova aquest camí exterior des de fora de la teva LAN, perquè una connexió que funciona dins de l’oficina no demostra res sobre la vora:

$ 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

Si el 1723 respon i la captura queda buida mentre el client intenta connectar-se, el camí està descartant el protocol 47. Un encaminador amb el 1723 reenviat però el pas PPTP desactivat produeix exactament aquest patró: l’apretada de mans TCP es completa, després els paquets GRE desapareixen, així que la fallada sembla un problema de credencials encara que no s’hagi intentat cap inici de sessió.

Apunta el reenviament a l’adreça LAN actual del servidor, activa el pas PPTP on l’encaminador l’ofereixi i torna-ho a provar des del mateix punt exterior. Quan el GRE es filtra aigües amunt i no ho pots canviar, SSTP sobre TCP 443 o L2TP/IPsec sobre UDP 500 i 4500 té més possibilitats que qualsevol canvi que puguis fer al costat de Windows.

L’error 812 és el servidor que rebutja el teu mètode d’autenticació

L’error 812 torna després que el túnel estigui aixecat, i per això sembla un problema de contrasenya. El servidor rebutja el mètode d’autenticació negociat per a la connexió, no necessàriament la contrasenya mateixa. Al client, obre l’entrada VPN, ves a la pestanya de seguretat, posa el tipus a Point-to-Point Tunneling Protocol, tria la llista explícita de protocols i marca Microsoft CHAP versió 2.

Pots llegir el paràmetre actual sense clicar pel diàleg:

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

Un servidor que exigeix MS-CHAP v2 rebutja un client deixat en PAP o en un tipus automàtic que negocia alguna cosa més feble, i l’error arriba abans que s’avaluï cap contrasenya d’usuari. El format del compte és l’altra meitat del mateix rebuig. En un cas, Windows va enviar una identitat de compte de Microsoft amb la forma MicrosoftAccount\[email protected] mentre el servidor volia un compte local o de domini. Escriure SERVERNAME\username va dir a Windows quin magatzem de comptes consultar i va esborrar l’error. Introdueix el nom a mà en lloc de deixar que una credencial desada reprodueixi un format anterior.

Els talls després d’un minut són una decisió de keepalive

Quan el túnel es connecta, passa una mica de trànsit i després es desconnecta, mira el comportament d’eco LCP del servidor abans de tocar el client. El dimoni demana periòdicament al parell que confirmi que encara hi és. Si arriben massa poques respostes dins del pressupost configurat, la sessió s’enderroca encara que l’usuari encara tingui un enllaç funcional.

En un servidor Linux pptpd aquests valors viuen a /etc/ppp/options.pptpd, i la reparació habitual és ampliar el pressupost en lloc d’escurçar l’interval:

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

Trenta fallades amb un interval de cinc segons perdonen una aturada breu en lloc de declarar que el parell ha desaparegut. Reduir el compte a un o dos converteix el jitter normal en un camí traduït en una desconnexió aproximadament cada minut. Si el teu servidor és Windows RRAS en lloc de pptpd, mira en canvi el temps d’espera de la sessió PPP i la política de desconnexió per inactivitat. Aquests viuen en un altre lloc, i editar un fitxer pppd que no existeix no canviarà res.

Les subxarxes superposades trenquen el camí de dades

Un túnel PPTP es pot autenticar netament i tot i així no arribar enlloc quan els dos llocs fan servir el mateix rang privat, per exemple 192.168.1.0/24 a l’oficina i a casa. El client no pot dir a quin amfitrió es refereix una adreça donada, i algunes piles refusen instal·lar la ruta del tot en lloc de triar-ne una.

Tracta-ho com un defecte de disseny i renumera un costat, o dona al client un rang d’accés traduït expressament. Depurar el client PPTP no pot arreglar un espai d’adreces que existeix dues vegades, i el símptoma continuarà semblant un tall aleatori.

Comença per l’etapa que ha fallat: GRE per al 800, el mètode i la cadena de compte per al 812, els paràmetres d’eco per a un túnel que mor segons l’horari.