Migrer d’un VPN basé sur PPP sans copier ses hypothèses

Une migration VPN est terminée quand les utilisateurs, les destinations, la résolution de noms et le comportement en cas de panne sont toujours corrects, pas quand le nouveau client affiche une icône verte. Les anciens déploiements basés sur PPP portent des hypothèses qui n’ont jamais été écrites : un secret partagé qui faisait aussi office de seule vérification d’identité, un pool d’adresses fixe que le pare-feu inscrit sur liste blanche, un suffixe DNS poussé par le serveur. Remplacer le protocole sans inventorier ces hypothèses produit un tunnel qui fait la poignée de main et une frontière qui n’existe pas. Le parcours ci-dessous est l’ordre que j’utilise, et la dernière étape est celle que les équipes sautent.

Étape 1 : inventoriez ce que fournit l’ancienne connexion

L’inventaire s’écrit, ne se retient pas. Notez les clients pris en charge, les rôles d’authentification, les pools d’adresses, les réseaux protégés, les exigences DNS et les autorisations de service dont chaque population d’utilisateurs a besoin.

Pour L2TP/IPsec, séparez explicitement les deux couches. L’identité du pair IPsec authentifie les machines ; PPP authentifie l’utilisateur, généralement avec CHAP ou MSCHAPv2.

C’est dans cette séparation que les anciens déploiements cachent leurs hypothèses. Une clé pré-partagée par tous les clients authentifie un groupe et non un appareil, et c’est souvent la seule chose qui ait jamais été renouvelée. Si le compte PPP est le véritable contrôle par utilisateur, dites-le, car la solution de remplacement doit reproduire ce contrôle avec autre chose qu’une chaîne partagée. Notez aussi les adresses source fixes et les exceptions de réseau local, car ce sont les dépendances que personne ne documente avant qu’elles cassent.

Étape 2 : concevez le remplacement délibérément

Choisir le remplacement, c’est une mise en correspondance exigence par exigence : un protocole et un client maintenu que l’organisation prend en charge, chaque exigence d’identité et d’accès aboutissant à un mécanisme réel. Un secret partagé n’équivaut pas automatiquement à une clé ou à un certificat par appareil, et un compte PPP par utilisateur n’équivaut pas à un certificat d’appareil.

Coordonnez les plages d’adresses avant tout le reste, car un pool de remplacement qui chevauche un LAN domestique ou de bureau crée une panne sans aucun rapport avec la robustesse du chiffrement. Vérifiez le pool par rapport à la même liste que celle établie pour l’ancien service, plus ce que le nouveau client suppose par défaut. Confirmez le routage de retour des réseaux protégés et confirmez que le nouveau client peut pousser ou documenter le suffixe DNS que l’ancien poussait. Ces deux points génèrent plus de tickets de migration que le changement de protocole lui-même.

Étape 3 : déployez par étapes et vérifiez à la fois l’autorisation et le refus

Déployez avec un utilisateur représentatif et une application représentative. Incluez la résolution DNS privée dans le test, car un tunnel qui atteint une adresse mais ne peut pas résoudre un nom interne n’est migré qu’à moitié. Incluez aussi l’état d’indisponibilité attendu : ce qui doit se passer quand le tunnel tombe, et si le client l’applique.

Testez ensuite une destination qui doit rester refusée. Une règle d’autorisation temporaire large peut faire paraître le nouveau tunnel en bonne santé tout en retirant discrètement la frontière d’autorisation que l’ancien service appliquait, et personne ne le remarque avant un audit. Comparez les résultats d’autorisation et de refus côte à côte, depuis le même client, dans la même session. Maintenez l’ancien service en marche jusqu’à ce que les deux colonnes correspondent à la conception.

Avant de déplacer l’accès administrateur, confirmez que vous disposez d’un chemin de récupération autorisé qui ne dépend pas du tunnel que vous modifiez.

Étape 4 : retirez l’ancienne identité

Retirer correctement l’ancienne identité, c’est révoquer les utilisateurs et les identifiants d’appareil obsolètes via le service qui les possède, puis supprimer les anciens profils et écouteurs une fois qu’aucune dépendance ne subsiste. Supprimer un fichier local ne révoque pas une copie ailleurs, et un ancien écouteur qui accepte encore l’ancien secret partagé est une porte sans surveillance.

Ce point mérite qu’on ralentisse. Un profil client décommissionné sur un ordinateur portable n’est pas un identifiant révoqué ; l’identifiant vit sur le serveur et reste valide jusqu’à ce que le serveur cesse de l’accepter. Cherchez d’autres copies de l’ancienne configuration — appareils de test, téléphone oublié, installateur que quelqu’un a conservé — et considérez l’arrêt de l’écouteur comme le moment où l’ancien service prend réellement fin. Jusque-là, la migration a deux portes d’entrée.

Le dossier d’acceptation est l’inventaire de la première étape avec une colonne ajoutée : ce que la nouvelle conception fait pour chaque ligne, et comment vous l’avez vérifié. Cela transforme une mise à niveau de protocole en exigence de service avec preuves.

Gardez le résultat lié à ce dont le service a besoin plutôt qu’au nom du protocole, car un protocole moderne avec les anciennes hypothèses copiées dedans est le même risque avec un meilleur habillage. RFC 3193 décrit comment L2TP est transporté sur IPsec, ce qui rappelle utilement que les deux couches ont toujours été des décisions distinctes. Si l’inventaire comporte une ligne que vous ne pouvez pas expliquer, arrêtez-vous et découvrez ce qui en dépend. La migration est terminée quand la liste est ennuyeuse.