LCP terminé par le pair sur PPTP : activez d’abord MPPE

La liaison s’authentifie, le client signale qu’il est connecté et, une seconde plus tard, le journal se ferme sur LCP terminé par le pair. Cette ligne vient de la négociation PPP à l’intérieur du tunnel GRE : le transport fonctionnait donc déjà et les deux extrémités ne s’accordaient pas sur les options de la liaison. Les mots de passe et les adresses de serveur sont généralement innocents ici. La politique de chiffrement est la première chose à comparer et, sous Linux, le fichier de pair de pppd est le premier endroit à consulter.

Ce que l’échec LCP dit de l’étape PPP

PPTP encapsule PPP dans GRE : la connexion de contrôle TCP 1723 établit l’appel, GRE transporte la charge utile, puis LCP négocie des options comme le protocole d’authentification, la compression et MPPE. Le pair termine LCP lorsqu’une option obligatoire n’est pas acceptable de son côté. Un journal où l’échange CHAP ou MSCHAPv2 se termine et où LCP s’arrête juste après est un refus de politique, pas une panne d’accessibilité. Si le tunnel n’atteint jamais la négociation, examinez pppd et son greffon avant de lire la ligne LCP.

Deux préconditions sont faciles à manquer. Le binaire pppd doit exister et le greffon PPTP nommé dans le fichier de pair doit être installé ; un paquet manquant met fin à l’appel avant que la moindre option soit discutée.

Activez MPPE du côté qui l’exige

La vraie décision est de savoir quelle extrémité détient la politique de chiffrement. Un client peut proposer MPPE, l’exiger ou le refuser, et le serveur fait le même choix. Quand les deux l’exigent, la liaison monte ; quand l’un l’exige et l’autre le refuse, LCP se termine.

pty "pptp vpn.example.net --nolaunchpppd"
name alice
remotename PPTP
require-mppe-128

Chargez le module avec modprobe ppp_mppe avant de composer, car require-mppe-128 échoue sans lui. Sous Windows, le réglage équivalent est l’onglet de sécurité de l’entrée VPN, où il faut demander au client d’exiger le chiffrement au lieu d’accepter ce que le serveur propose. Si le serveur termine encore LCP, demandez à son exploitant si MPPE est obligatoire, facultatif ou désactivé, car un client ne peut pas négocier une protection que le serveur refuse. Désactiver le chiffrement pour faire disparaître le message est la mauvaise direction : cela supprime la seule protection dont dispose ce protocole.

Enregistrez le fichier de pair qui fonctionne avant de le modifier. Une ligne require-mppe mal saisie reproduit le même échec LCP générique et vous renvoie au point de départ.

Lisez le journal de pppd plutôt que l’applet

Les applets de bureau affichent la déconnexion et cachent la raison, alors lisez le récit du démon pour une tentative. Sur les systèmes systemd, le message atterrit dans le journal ; les installations plus anciennes écrivent dans les fichiers journaux traditionnels.

journalctl --since "10 min ago" | grep -i -E "pppd|lcp|mppe"
tail -n 50 /var/log/syslog

Cherchez dans une fenêtre autour d’un seul appel plutôt que sur une journée entière de reconnexions, afin que l’option refusée soit facile à repérer. pppd nomme généralement l’option et la réponse du pair, ce qui vous dit s’il faut modifier votre propre proposition ou demander au côté serveur d’assouplir son exigence. Gardez les tentatives horodatées, car comparer deux journaux n’est utile que si vous savez quelles lignes appartiennent à quel appel. Quand aucun échange LCP n’apparaît du tout, la panne se situe plus haut dans la chaîne et MPPE n’est pas le suspect.

Conservez le correctif entre les reconnexions : noms de hooks et MTU

Une fois la liaison stable, deux détails décident si elle survit à une reconnexion. Les hooks vivent dans /etc/ppp/ip-up.d et /etc/network/if-up.d, et run-parts traite les deux répertoires, son filtre de noms de fichiers rejetant tout ce qui contient un point. Un script nommé set-pptp.sh est donc ignoré, tandis que set-pptp s’exécute. Vérifiez le nom avant de déboguer le contenu du script, puis réglez la MTU plus petite depuis ce hook afin que chaque nouvelle interface ppp en hérite sans commande manuelle.

run-parts --test /etc/ppp/ip-up.d
ip link set dev ppp0 mtu 1200

Pour terminer une session volontairement, visez le pid enregistré par pppd plutôt que de faire correspondre des noms de processus, car tuer tout ce qui contient ppp démonte aussi des liaisons sans rapport. PPTP est obsolète et MS-CHAPv2 est faible, alors traitez ces vérifications comme de la maintenance pour une liaison qui doit continuer à fonctionner, non comme une raison de déployer PPTP ailleurs.