Pourquoi PPP CHAP seul ne peut pas satisfaire une exigence MPPE

Un profil PPTP qui exige le chiffrement échoue généralement au même endroit : PPP s’accorde sur un échange d’authentification qui ne produit jamais la matière de clé dont MPPE a besoin. Le tunnel paraît à moitié vivant, le mot de passe est accepté et le lien tombe avant qu’aucun trafic ne le traverse. Se rabattre sur la liste déroulante CHAP jusqu’à ce que quelque chose se connecte masque le vrai défaut, qui est un contrat entre la méthode d’authentification et la politique de protection. Les vérifications ci-dessous sont ordonnées pour que chacune écarte une cause moins coûteuse que la suivante.

Deux négociations se déroulent dans une seule connexion PPTP

PPTP transporte une session PPP normale dans un tunnel GRE, et les deux négocient séparément. La couche externe décide comment les paquets sont encapsulés et quel canal de contrôle existe ; la session PPP interne décide qui est le pair et quelle protection repose dessus. Une invite de mot de passe ne prouve donc quelque chose que pour la couche interne, et une poignée de main externe terminée ne prouve rien pour aucune des deux. Les profils échouent ici parce que les gens déboguent le tunnel alors que le désaccord siège dans PPP.

CHAP simple est l’échange défi-réponse de la RFC 1994, bâti sur un secret partagé et rien d’autre. MS-CHAPv2 est un autre échange, avec d’autres messages et une autre sortie, normalisé dans la RFC 2759. Le mot commun aux deux noms est la seule chose qu’ils partagent sur le fil. Aucun des deux noms ne dit ce que l’échange produit, et c’est la seule partie qui compte.

C’est pourquoi une option simplement libellée CHAP est ambiguë dans un profil ancien. Quand le serveur veut MS-CHAPv2 et que le client propose CHAP simple, le contrôle de lien peut encore aboutir et un mot de passe peut encore être accepté. La panne arrive plus tard, quand le serveur tente de dériver des clés de protection d’un échange qui n’en a produit aucune.

Faites correspondre la méthode exigée aux clés qu’elle peut produire

Les clés MPPE ne sont pas une propriété de PPP en général. Pour la famille Microsoft CHAP, la dérivation est spécifiée dans la RFC 3079, et elle prend en entrée la sortie d’un échange MS-CHAP plutôt qu’un secret partagé. Les méthodes EAP arrivent au même point par une autre voie, le serveur d’authentification renvoyant les clés comme attributs MS-MPPE-Recv-Key et MS-MPPE-Send-Key. CHAP simple n’apparaît dans aucune des deux voies, et c’est toute la raison d’être de l’inadéquation.

Une configuration qui exige MPPE tout en refusant toute méthode capable de fournir des clés est intérieurement contradictoire. pppd résout cette contradiction en refusant le lien, pas en inventant des clés, si bien que le résultat visible est une session qui s’authentifie puis se termine pendant la phase réseau. Réessayer le client n’y changera rien tant que le serveur refuse les seules méthodes qui dérivent quoi que ce soit.

La règle qui en découle est courte : si le profil exige MPPE, la méthode doit être une variante MS-CHAP ou une méthode EAP dont le serveur renvoie les clés. Refuser seulement MS-CHAPv2 ne l’impose pas, car MS-CHAPv1 dérive aussi des clés et reste disponible sauf refus séparé ; refuser les deux laisse CHAP simple et PAP, qui ne dérivent rien et rendent l’exigence insatisfaisable. Nommez explicitement la méthode acceptée au lieu de lister celles que vous n’aimez pas. Abandonner l’exigence de chiffrement pour qu’un client se connecte est une dégradation, pas une réparation.

Lisez les options du serveur avant de modifier un client

La plupart de ces inadéquations sont visibles sur le serveur dans deux fichiers, et les lire coûte moins que de reconstruire un client. Sur un point de terminaison PPTP Linux, les réglages pertinents vivent dans le fichier d’options pppd que pptpd transmet. Exécutez-le sur le serveur, pas depuis un écran d’état du client. Commencez par les lignes qui exigent, refusent ou nomment un mode de protection :

sudo grep -nE 'require-|refuse-|mppe|mschap' /etc/ppp/options.pptpd

Lisez la sortie comme un contrat plutôt que comme une liste de drapeaux. Une ligne qui exige MPPE tout en refusant les deux variantes MS-CHAP ne peut être satisfaite par aucun client, et une exigence absente pour une méthode MS-CHAP laisse la porte ouverte aux échanges qui ne donnent aucune clé. Vérifiez ensuite qui peut s’authentifier tout court, ce que décide le fichier de secrets :

sudo sed -n '1,20p' /etc/ppp/chap-secrets
sudo pppd --version

Notez trois valeurs avant de changer quoi que ce soit : le protocole externe, la méthode d’authentification exigée par le serveur et le caractère obligatoire ou facultatif de la protection. Ces trois déterminent chaque décision ultérieure, et les deviner depuis une boîte de dialogue client est la façon dont un profil finit à moitié configuré. Gardez le fichier ouvert pendant le travail, car la section suivante a besoin des mêmes trois valeurs.

Localisez la panne par phase PPP

PPP signale les pannes par phases, et la phase dit quelle clause du contrat s’est rompue. Un lien qui ne quitte jamais le contrôle de lien a un problème d’encapsulation ou de négociation, tandis que celui qui s’authentifie puis meurt a généralement un problème de politique ou de clé. Un lien qui reste levé et ne transporte rien est passé au routage, ce qui est une autre enquête.

Le journal conserve les lignes de phase, et elles sont plus utiles qu’un niveau de débogage plus élevé. Demandez les processus PPP et les messages de protection, puis lisez le résultat d’authentification avant tout le reste. Les dernières lignes nomment généralement la clause qui a refusé :

sudo journalctl -b --no-pager | grep -iE 'pppd|pptpd|mppe|chap' | tail -40

Dans cette sortie, cherchez d’abord le résultat d’authentification, puis une plainte selon laquelle la protection était exigée mais n’a pas été négociée. Le second message est la signature de la contradiction ci-dessus, et aucune quantité de nouvelles tentatives ne l’efface tant que le serveur refuse la seule méthode capable de produire des clés. Deux pièges méritent d’être nommés : augmenter le niveau de débogage sans lire les lignes de phase produit du bruit, et capturer la matière du défi ou des mots de passe transforme une tâche de configuration en fuite d’identifiants. Notez cette phase avant de changer la moindre option.

Planifiez la sortie avant que l’ancien point de terminaison ne soit éteint

MPPE est un mécanisme historique de protection de lien, et sa présence ne fait pas de PPTP un choix raisonnable pour un nouveau déploiement. Les recommandations actuelles de Microsoft déconseillent déjà PPTP et L2TP/IPsec avec une clé prépartagée pour les nouveaux déploiements d’accès distant. Maintenir en vie un point de terminaison hérité est une décision sur un service existant, pas un modèle pour le suivant.

Quand le point de terminaison doit rester, écrivez le contrat : protocole externe, méthode d’authentification requise, protection obligatoire et la version de client qui la négocie. Quand il peut partir, choisissez l’identité de passerelle du remplaçant, son authentification client et l’endroit où vivront les identifiants avant de toucher l’ancien profil. Planifiez ensuite les routes, le DNS et les ressources auxquelles chaque utilisateur est autorisé. Validez le client prévu par rapport aux exigences du propriétaire, pas par rapport à une connexion qui fonctionne.

Un refus délibéré doit rester un refus, car retomber sur un mode non protégé pour faire passer un test transforme un échec de politique en exposition. L’état final est un contrat pris en charge et documenté, pas le plus petit ensemble de changements qui fait réussir une vieille connexion. Laissez l’ancien profil en place, inutilisé et documenté, jusqu’à ce que le remplaçant passe les mêmes vérifications.