Migrer l’accès VPN vers un nouveau Mac : ce qu’il faut noter d’abord

La migration échoue en silence : la connexion apparaît dans la barre des menus, le profil s’importe et l’authentification échoue quand même parce que le nouveau Mac n’est pas un appareil autorisé. L’ancien Mac continue de fonctionner, ce qui permet de repousser la panne jusqu’à la disparition de la vieille machine. Un inventaire court avant le changement évite l’essentiel. Notez de quoi l’accès dépend tant que vous pouvez encore le lire sur la machine qui fonctionne.

Inventoriez l’accès pendant que l’ancien Mac se connecte encore

Commencez par le client et le protocole, pas par le nom de la connexion. Le nom est une étiquette choisie par l’ancien profil ; la version du client, le protocole et le point de terminaison sont ce que la nouvelle machine doit reproduire. Notez aussi le nom d’hôte exact du point de terminaison, car une migration du fournisseur peut le déplacer sans changer l’étiquette.

L’entrée d’identité pèse le plus lourd. Un nom d’utilisateur et un code à usage unique peuvent être saisis sur le nouveau Mac, un certificat avec clé exportable peut parfois être importé, et un certificat lié à l’appareil avec une clé non exportable ne peut pas être déplacé du tout. Notez lequel de ces cas s’applique avant de planifier le basculement. Si deux de ces réponses se contredisent, réglez la contradiction avant de copier quoi que ce soit.

Enfin, notez le comportement réseau attendu : tunnel complet ou tunnel fractionné, quels noms internes doivent être résolus et si IPv6 doit circuler dans le tunnel. Cela devient les tests qui décident si la migration a fonctionné.

Séparez ce qui peut être copié de ce qui doit être réémis

Les profils utilisateur, les adresses de serveur et les préférences sont généralement transférables. Les clés privées, les certificats d’appareil et les jetons d’enrôlement ne le sont pas, car leur valeur dépend d’un lien à une seule machine. Traitez-les comme des éléments à réémettre et demandez au propriétaire le chemin pris en charge. Tout le reste peut être copié. C’est le processus du propriétaire, pas l’assistant de migration, qui décide de la catégorie applicable.

Arrêtez-vous ici si l’identité est liée à l’appareil et qu’aucune voie de réémission n’existe. Continuer avec une clé copiée échoue à l’authentification ou, pire, laisse la même information d’identification active sur deux machines sans aucune trace de la seconde.

Ne déposez pas une clé privée ni un code de récupération dans une note ou un message de discussion pendant le transfert. Utilisez le trousseau, le gestionnaire de mots de passe ou le processus de séquestre de l’organisation, et réenrôlez l’authentificateur au lieu de copier sa graine. Une note de migration qui contient un identifiant devient une seconde copie de cet identifiant.

Préparez le nouveau Mac par le chemin pris en charge

Si le Mac est géré, enrôlez-le dans le même système de gestion avant d’ajouter une configuration manuelle. Le système de gestion détient le profil imposé, et un profil importé à la main par-dessus crée deux sources de vérité qui divergent après le prochain changement de politique.

Sur un Mac non géré, installez le client depuis le téléchargement actuel du fournisseur et importez le profil par la méthode documentée par le fournisseur. Les versions récentes de macOS exigent une approbation pour les configurations VPN et les extensions système dans Confidentialité et sécurité, et une extension peut nécessiter un redémarrage avant que le tunnel démarre. Apple documente le chemin de configuration manuelle du VPN si vous voulez le comparer à l’application du fournisseur.

Supprimez les définitions en double une fois que la nouvelle fonctionne. Une entrée obsolète dans les réglages Réseau et le profil propre à l’application peuvent tous deux pointer vers le même point de terminaison, et celle qui se connecte n’est pas toujours celle que vous croyez avoir modifiée.

Testez les chemins que le nouveau Mac utilisera réellement

Connectez-vous et confirmez que le tunnel transporte du trafic ; vérifiez ensuite la résolution de noms et le routage plutôt que de faire confiance à l’icône de la barre des menus. macOS signale les résolveurs par interface, donc le serveur DNS interne doit apparaître sur l’interface du tunnel et les noms internes doivent se résoudre par son intermédiaire. Les deux commandes ci-dessous ne font que lire l’état.

scutil --dns | head -40
netstat -rn -f inet | head -20
netstat -rn -f inet6 | head -20

Arrêtez-vous si un nom d’hôte interne se résout en adresse publique ou si la route par défaut pointe encore vers l’interface physique alors que la conception prévoit un tunnel complet. Les deux indiquent que le profil a été importé sans ses routes ou qu’une autre configuration le supplante.

Répétez le test après la veille et après le passage à un autre réseau. Une connexion qui survit à la première ouverture de session mais pas à la fermeture du capot est une migration qui échouera au quotidien, et la détecter avant d’effacer l’ancien Mac est tout l’intérêt de la liste.

Mettez l’ancien Mac hors service et révoquez-le

Gardez l’ancien appareil connecté jusqu’à ce que le nouveau passe les tests ci-dessus. Révoquez ensuite l’ancien appareil via la console de l’opérateur ou le système de gestion ; supprimer l’application sur l’ancien Mac ne révoque pas son identité, et un profil copié peut encore s’authentifier.

Après la révocation, supprimez les profils, déconnectez-vous du compte et effacez le disque si la machine quitte votre contrôle. Vérifiez une dernière fois la liste d’appareils du fournisseur pour confirmer que l’ancienne entrée a disparu et que la nouvelle est correctement étiquetée.

Si un secret partagé ou un identifiant d’équipe a été copié pendant le transfert, faites-le tourner maintenant plutôt que d’attendre le prochain changement planifié. La migration est terminée quand l’ancienne identité est morte, pas quand la nouvelle icône devient verte.