Des mots de passe de vingt caractères, renouvelés chaque mois et conservés dans un coffre, ne transforment pas un serveur PPTP sous MS-CHAPv2 en VPN moderne. Le mot de passe est une entrée d’un échange dont la faiblesse réside dans l’échange lui-même. Ce mode opératoire s’adresse à qui a hérité de ce serveur et doit déplacer les utilisateurs sans couper le site qui en dépend. Suivez les étapes dans l’ordre, car chacune laisse une trace dont vous aurez besoin quand quelqu’un demandera pourquoi l’accès a soudain changé.

Écrivez la pile avant de toucher à quoi que ce soit

Trois couches se confondent dans le mot PPTP, et chacune échoue à sa manière. Le tunnel est PPTP lui-même, GRE plus TCP 1723. L’authentification est la méthode PPP que le serveur propose, ici MS-CHAPv2. La protection du lien est MPPE, dont les clés dérivent de cet échange d’authentification. Nommer les trois évite qu’une correction ultérieure atterrisse sur la mauvaise couche.

Lisez la configuration vivante plutôt que de faire confiance à une page wiki, et notez le fichier, l’écouteur et les dernières sessions qui se sont authentifiées.

grep -RniE 'mschap|mppe|require-mppe' /etc/ppp/options.pptpd /etc/pptpd.conf
ss -lntp 'sport = :1723'
journalctl -u pptpd -n 40 --no-pager

Sur un rôle d’accès distant Windows, le même inventaire vient de deux commandes, et la seconde compte parce qu’un rôle peut annoncer plusieurs méthodes à la fois tandis que les clients du terrain ne négocient jamais que la plus faible.

Get-VpnAuthProtocol
netstat -ano | findstr :1723

Décidez de ce que le tunnel transporte réellement aujourd’hui

Listez les consommateurs avant de choisir un remplacement : portables en itinérance, un routeur d’agence, un terminal de paiement, un ensemble de tablettes de terrain. Un consommateur qui n’a besoin d’atteindre qu’un hôte interne est facile à déplacer. Un consommateur intégré à du matériel que vous ne pouvez pas reflasher peut avoir besoin d’une passerelle intermédiaire plutôt que d’une mise à niveau du client, et cette décision relève du plan, pas du milieu de la bascule.

Demandez ensuite ce qu’obtiendrait un attaquant qui peut observer ou influencer l’échange de connexion. Avec MS-CHAPv2, la réponse comprend de quoi récupérer hors ligne le mot de passe de l’utilisateur, et c’est précisément pourquoi la longueur et la rotation ne réparent pas la conception : le secret récupéré est valide sur chaque système où l’utilisateur l’a réutilisé.

MPPE hérite de la même faiblesse, puisque ses clés viennent de cet échange, et il ne vous donne ni l’intégrité par paquet ni le comportement de rejeu d’un chiffrement AEAD moderne. Une session qui s’authentifie proprement a prouvé sa compatibilité avec les contrôles configurés et rien de plus.

Ni une courte pause déjeuner ni un petit nombre d’utilisateurs ne transforment une propriété cryptographique en propriété de politique.

Menez la migration dans une seule fenêtre de maintenance

Montez le remplacement, prouvez-le avec un groupe pilote, puis arrêtez l’ancien écouteur au lieu de le laisser comme repli silencieux. Un repli que tout le monde peut encore joindre n’est pas une migration, et il garde l’échange faible disponible précisément pour les utilisateurs qui ne prennent jamais la peine de changer.

sudo systemctl disable --now pptpd
sudo ss -lntp | grep -E ':(1723|1194|51820)\b'
sudo nft list ruleset | grep -i gre

Fermez le chemin du pare-feu dans la même fenêtre. GRE n’a pas de port à retenir, donc une règle autorisant le protocole 47 par numéro passe facilement inaperçue et laisse le service joignable même après le départ du démon. Consignez la règle supprimée, sa position précédente et la raison, pour qu’une revue de changement ultérieure ne la rétablisse pas par accident.

Traitez les identifiants séparément de la configuration. Supprimer un profil client n’est pas une révocation, et un compte qui s’authentifie encore ailleurs n’a pas été retiré.

Vérifiez que le remplacement fait le travail que faisait PPTP

La liste de contrôle n’est pas « est-ce que ça se connecte ». C’est si l’authentification, l’attribution d’adresses, la résolution DNS, la sélection de route, le comportement de reconnexion et la vérification du pair tiennent encore sous le remplacement. Testez chacun sur un appareil pilote, dans cet ordre, et écrivez le résultat observé à côté de l’attendu.

ip -4 addr show tun0
ip route get 198.51.100.23
resolvectl query intranet.example.net

Une adresse sur l’interface prouve que la négociation a abouti. Elle ne prouve pas que le côté distant a autorisé la route que vous attendez, et la requête ci-dessus ne répond que pour cet hôte, pas pour un LAN transféré. Une réponse de résolveur prouve l’accessibilité d’un résolveur, pas que la politique de DNS scindé lui envoie les bons noms.

Reconnectez en dernier, car c’est là que la plupart des remplacements régressent : mettez un portable en veille, changez de réseau et confirmez que le tunnel se rétablit sans laisser de routes obsolètes.

Retour arrière, révocation et la trace que vous laissez

Le retour arrière restaure le service ; il ne restaure pas la sécurité, et la différence doit être dite à voix haute avant l’ouverture de la fenêtre. Si le nouveau chemin échoue, ramenez les utilisateurs par un second point de terminaison moderne ou une passerelle temporaire, non en réactivant PPTP pour tout le monde. Garder un chemin d’urgence sur l’ancien protocole élargit l’exposition que vous venez de documenter.

Après la bascule, révoquez les comptes qui se sont authentifiés via PPTP, laissez expirer leurs profils stockés et confirmez que la règle GRE a disparu de chaque équipement de bord, y compris la copie de reprise après sinistre dont personne ne se souvient.

Laissez une trace courte : les protocoles trouvés, la date d’arrêt de chaque écouteur, les versions de client prises en charge par le remplacement et le propriétaire qui peut rouvrir la décision. L’hygiène des mots de passe compte encore ensuite, mais comme hygiène sur un protocole qui la mérite, non comme argument pour maintenir l’ancien en vie.

Articles similaires