VPN du Mac bloqué sur « Déconnexion » : ce qui tourne vraiment

La déconnexion est une transition, pas un tunnel arrêté. Vérifiez quel composant possède le démontage, lisez les routes et le DNS, et évitez de tuer des processus à l'aveugle.

« Déconnexion » est un état que le client signale pendant qu'il démonte un tunnel, pas un verdict que le trafic s'est arrêté. Sur un Mac, ce démontage se déroule en une courte séquence, et le libellé ne change qu'une fois que le composant propriétaire de la connexion a répondu. Quand une étape attend un assistant, un greffon ou une décision de stratégie, le libellé peut rester en place après la disparition de l'interface, ou le tunnel peut continuer à transmettre alors que le menu l'affiche encore. Traitez le texte comme « démontage en cours, résultat inconnu » et déterminez laquelle des deux moitiés est vraie.

Deux pannes se ressemblent depuis la barre des menus et appellent des réponses opposées. Dans l'une, le tunnel transporte encore des paquets et seul l'affichage est périmé. Dans l'autre, le tunnel a disparu mais une stratégie distincte maintient le trafic bloqué, ce qui est souvent délibéré. Les routes et l'état du DNS les séparent plus vite que n'importe quelle manipulation du menu.

Ce que le libellé suit

Un client VPN tient une petite machine à états, et la barre des menus en est une projection. Pour une connexion gérée par macOS lui-même, cette machine siège dans le cadre VPN du système. Pour un tunnel géré par une application, elle siège dans l'application et son assistant privilégié. La dernière étape d'un arrêt n'est pas de fermer une socket. C'est de libérer ce qui faisait fonctionner le tunnel : l'interface utun, les routes qui pointaient vers elle, les entrées de résolveur injectées par le client et toute règle de pare-feu ou stratégie qui bloquait le trafic pendant la connexion.

Ces étapes sont distinctes, donc un arrêt peut se bloquer sur n'importe laquelle. Un assistant qui cesse de répondre, une route que revendique aussi une seconde interface ou une entrée de résolveur possédée par un autre profil peuvent laisser le client en attente. Le libellé est un rapport sur la progression du client lui-même, ce qui le rend fiable sur l'intention et peu fiable sur le réseau.

Trouvez le composant propriétaire de la connexion

Pour les configurations natives, scutil --nc list affiche les services connus du système et leur état, et scutil --nc status "Work VPN" donne le détail d'un service. Un tunnel tenu par une application tierce peut ne pas apparaître du tout dans cette liste, donc un résultat vide ne prouve pas que rien n'est connecté.

Quand le profil appartient à une application, fiez-vous à sa vue d'état et à sa commande « Déconnecter » documentée. Fermer la fenêtre n'est pas une demande d'arrêt si un assistant en arrière-plan possède le tunnel ; l'icône disparaît et l'assistant maintient l'interface en vie. La référence des réglages VPN d'Apple couvre les commandes natives et l'origine des réglages gérés.

Lisez les interfaces, les routes et le DNS

Trois vérifications répondent à l'essentiel de la question sans toucher à la connexion. C'est leur interprétation conjointe qui compte, car chacune seule induit en erreur.

scutil --nc list
netstat -rn -f inet | head -20
ifconfig | grep -A 3 '^utun'
scutil --dns | head -30
  • interface utun présente, route par défaut ou fractionnée à travers elle, résolveur pointant vers le fournisseur : le tunnel est toujours actif et le libellé est périmé.
  • pas d'utun, route par défaut ordinaire, DNS en DHCP, pas d'internet : une stratégie qui bloque une fois déconnecté fait son travail.
  • pas d'utun, pas de route, résolveur pointant toujours vers le fournisseur : le démontage s'est arrêté à mi-chemin, et le DNS est le reste à nettoyer.

Envoyez ensuite une requête vers un hôte interne qui ne devrait répondre que par le tunnel et une vers un hôte public. L'accessibilité sépare la stratégie de l'état résiduel sans transformer la vérification en exercice de mesure. Enregistrez d'abord le travail distant si le chemin répond encore, et prévoyez un second accès avant de changer le réseau sur une machine que vous administrez à distance.

Pourquoi les tuées massives et la suppression du profil trompent

Des noms de processus comme pppd, racoon et configd appartiennent à des implémentations précises. Les tuer peut affecter d'autres connexions, laisse des routes et des interfaces utun derrière et ne vous donne aucune trace de l'étape bloquée. Un ancien nom de processus n'est pas non plus la preuve qu'il possède le profil actuel.

Supprimer et recréer le profil est un changement plus lourd que de nettoyer une transition bloquée. Cela peut écarter des réglages gérés et du matériel d'identité local sans expliquer ce qui a échoué, et sur un Mac surveillé il peut simplement être restauré. Réservez la suppression à une configuration réellement obsolète et diagnostiquez plutôt la transition.

Une séquence d'arrêt qui laisse une trace

L'ordre ci-dessous laisse les commandes propres à la connexion aux commandes et produit un enregistrement si le blocage revient. Il vous évite aussi de transformer un problème d'affichage en changement réseau.

  1. Enregistrez le travail distant et confirmez que vous pouvez joindre le Mac autrement s'il est distant.
  2. Notez le nom du client, la version et le profil. Capturez une courte fenêtre avec log show --last 5m --predicate 'subsystem == "com.apple.networkextension"' ; les versions plus anciennes gardent moins d'historique, alors lancez-la peu après le blocage.
  3. Utilisez la commande « Déconnecter » documentée, attendez, puis répétez les vérifications d'interface et de routes.
  4. Si le libellé est périmé mais le tunnel arrêté, laissez-le et laissez le client se rafraîchir au lieu de forcer des processus.
  5. Si le démontage s'est réellement bloqué, redémarrez le client, puis planifiez un redémarrage du Mac une fois le travail enregistré. Les machines gérées exigent la procédure de l'administrateur.

Après la reprise, confirmez que la route par défaut ordinaire et le résolveur DHCP sont revenus, et que le trafic bloqué est soit rétabli, soit toujours bloqué volontairement. Notez le profil et la version du client avec le symptôme, pour que la prochaine occurrence parte de preuves plutôt que d'une supposition dans la barre des menus.

Articles similaires