Erreur PPTP 800 contre 812 et coupures après une minute

Trois messages d’erreur d’un même client PPTP décrivent généralement trois pannes différentes. L’erreur 800 signifie que le tunnel ne s’est jamais formé, l’erreur 812 signifie que le serveur a refusé la méthode d’authentification, et une coupure au bout d’une minute est un minuteur keepalive qui décide qu’un pair sain a disparu. Chaque étape échoue pour sa propre raison, donc chacune demande sa propre vérification.

L’erreur 800 signifie que le tunnel ne s’est jamais formé

Windows remonte l’erreur 800 lorsqu’il ne peut pas construire le tunnel du tout, et le texte sur un serveur injoignable ou des paramètres de sécurité inadaptés est un résumé et non un diagnostic. PPTP a besoin de deux choses distinctes du réseau avant qu’un identifiant quelconque soit examiné. TCP 1723 transporte le canal de contrôle, et le protocole IP 47, GRE, transporte la charge encapsulée.

Testez ce chemin extérieur depuis l’extérieur de votre propre LAN, car une connexion qui fonctionne au bureau ne prouve rien sur la bordure :

$ 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 1723 répond et que la capture reste vide pendant que le client tente de se connecter, le chemin laisse tomber le protocole 47. Un routeur avec 1723 redirigé mais le passthrough PPTP désactivé produit exactement ce schéma : la poignée de main TCP se termine, puis les paquets GRE disparaissent, si bien que la panne ressemble à un problème d’identifiants alors qu’aucune tentative de connexion n’a eu lieu.

Pointez la redirection vers l’adresse LAN actuelle du serveur, activez le passthrough PPTP là où le routeur le propose, et réessayez depuis le même point extérieur. Quand GRE est filtré en amont et que vous ne pouvez pas y changer quoi que ce soit, SSTP sur TCP 443 ou L2TP/IPsec sur UDP 500 et 4500 a de meilleures chances que n’importe quelle modification côté Windows.

L’erreur 812 est le serveur qui refuse votre méthode d’authentification

L’erreur 812 revient une fois le tunnel monté, c’est pourquoi elle ressemble à un problème de mot de passe. Le serveur refuse la méthode d’authentification négociée pour la connexion, pas nécessairement le mot de passe lui-même. Sur le client, ouvrez l’entrée VPN, allez à l’onglet sécurité, réglez le type sur Point-to-Point Tunneling Protocol, choisissez la liste explicite de protocoles et cochez Microsoft CHAP version 2.

Vous pouvez lire le réglage actuel sans passer par la boîte de dialogue :

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

Un serveur qui exige MS-CHAP v2 refuse un client resté sur PAP ou sur un type automatique qui négocie quelque chose de plus faible, et l’erreur arrive avant qu’un quelconque mot de passe utilisateur soit évalué. Le format du compte est l’autre moitié du même refus. Dans un cas, Windows a envoyé une identité de compte Microsoft de la forme MicrosoftAccount\[email protected] alors que le serveur voulait un compte local ou de domaine. Saisir SERVERNAME\username a indiqué à Windows quel magasin de comptes consulter et a levé l’erreur. Saisissez le nom à la main au lieu de laisser un identifiant enregistré rejouer un format antérieur.

Les coupures après une minute sont une décision de keepalive

Quand le tunnel se connecte, passe un peu de trafic puis se déconnecte, regardez le comportement d’écho LCP du serveur avant de toucher au client. Le démon demande périodiquement au pair de confirmer qu’il est toujours là. Si trop peu de réponses arrivent dans le budget configuré, la session est démontée alors que l’utilisateur a encore une liaison fonctionnelle.

Sur un serveur Linux pptpd ces valeurs vivent dans /etc/ppp/options.pptpd, et la réparation habituelle consiste à élargir le budget plutôt qu’à raccourcir l’intervalle :

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

Trente ratés à un intervalle de cinq secondes pardonnent un bref blocage au lieu de déclarer le pair disparu. Réduire le compte à un ou deux transforme la gigue ordinaire sur un chemin traduit en déconnexion à peu près chaque minute. Si votre serveur est Windows RRAS plutôt que pptpd, regardez plutôt le délai d’expiration de session PPP et la stratégie de déconnexion en cas d’inactivité. Ceux-là vivent ailleurs, et modifier un fichier pppd qui n’existe pas ne changera rien.

Les sous-réseaux qui se chevauchent cassent le chemin de données

Un tunnel PPTP peut s’authentifier proprement et n’atteindre rien du tout quand les deux sites utilisent la même plage privée, par exemple 192.168.1.0/24 au bureau et à la maison. Le client ne peut pas dire à quel hôte une adresse donnée renvoie, et certaines piles refusent carrément d’installer la route au lieu d’en choisir une.

Traitez cela comme un défaut de conception et renumérotez un côté, ou donnez au client une plage d’accès traduite exprès. Déboguer le client PPTP ne peut pas réparer un espace d’adresses qui existe deux fois, et le symptôme continuera de ressembler à une coupure aléatoire.

Commencez par l’étape qui a échoué : GRE pour 800, la méthode et la chaîne de compte pour 812, les réglages d’écho pour un tunnel qui meurt à l’heure prévue.