Le VPN du Mac se connecte une fois puis expire : nettoyez le démon IKE

La première connexion après un redémarrage fonctionne. Chaque tentative suivante reste bloquée à l’étape de connexion et finit par expirer, et le seul remède fiable est un autre redémarrage. Ce schéma n’est pas un problème de profil et ce n’est pas un problème d’identifiants. Quelque chose en arrière-plan retient encore l’état de la tentative précédente, et la tentative suivante entre en collision avec.

Sous macOS, ce quelque chose est généralement le démon IKE.

Le schéma : une connexion, puis une expiration

Une connexion qui fonctionne exactement une fois par démarrage indique un état qui survit à une déconnexion mais pas à un redémarrage. Les profils survivent aux deux, donc le profil n’est pas la variable. Les identifiants survivent aussi aux deux, sauf si le serveur verrouille le compte. Ce qui change au redémarrage, c’est l’ensemble des démons en cours d’exécution et les sockets qu’ils détiennent.

Cela resserre l’enquête avant même d’ouvrir un seul journal. La question devient quel processus possède le port IKE et ce qu’il croit faire.

Deux démons, un seul port

Le système exécute racoon lorsqu’une connexion parle IKE version 1. Les versions actuelles apportent aussi iked pour IKEv2 et la pile IPsec plus récente. Les deux peuvent occuper l’UDP 500 et l’UDP 4500, et les deux peuvent conserver une association de sécurité entrouverte après qu’une tentative de connexion est annulée à l’invite de mot de passe ou interrompue par un changement de réseau.

Quand cela se produit, la tentative suivante ne démarre pas proprement. Elle tente de négocier alors que l’ancienne association occupe encore l’état du pair, et l’échange cale au lieu d’échouer avec une erreur claire. L’utilisateur voit un indicateur d’attente, puis une expiration.

Trouvez le propriétaire avant de tuer quoi que ce soit, car la réponse détermine quel service vous redémarrez et quel journal vous lirez ensuite.

sudo lsof -i :500 -i :4500
ps -ef | grep -E "racoon|iked"

Lisez la sortie comme deux faits : quel processus détient le port, et s’il y en a plus d’un. Deux démons IKE qui se disputent le même socket expliquent beaucoup de comportements intermittents qui ressemblent à un serveur instable.

Redémarrez la tâche plutôt que le processus

Sur les systèmes plus anciens, tuer le processus et laisser la connexion suivante le relancer suffit. Sur les versions actuelles, le démon est géré par launchd, et signaler le processus seul peut laisser la tâche dans un état où elle ne tourne pas et n’est pas programmée pour démarrer. Arrêtez puis démarrez la tâche à la place.

sudo launchctl stop com.apple.racoon
sudo launchctl start com.apple.racoon

Si launchd n’a aucune entrée pour la tâche, tuer le processus par son nom force tout de même une négociation neuve à la tentative suivante. Le test est le même dans les deux cas : aucun processus ne devrait détenir le port quand vous essayez de vous reconnecter. Confirmez-le avec la même commande lsof au lieu de supposer que le redémarrage a fonctionné.

Connectez-vous ensuite une fois et lisez le journal du client depuis le début. Une négociation qui dépasse la phase 1 puis signale un échec de transmission répète le problème local de socket ; une négociation rejetée par le pair est un ticket complètement différent.

Quand c’est le serveur qui refuse

Ce n’est pas chaque seconde connexion qui échoue localement. Un serveur peut refuser une nouvelle connexion pendant une fenêtre fixe après une déconnexion, et l’expiration côté client ressemble à s’y méprendre à un démon bloqué. Le discriminant est bon marché : si redémarrer le démon n’aide pas mais qu’un autre compte se connecte immédiatement, la fenêtre est côté serveur et le Mac n’a jamais été le problème.

La politique de tunnel divisé produit la même forme dans l’autre sens. Un serveur qui exige tout le trafic dans le tunnel rejettera un client configuré pour le tunnel divisé pendant la négociation, et le client signale une expiration plutôt qu’un refus de politique. Modifier le profil pour tout envoyer dans le tunnel peut le faire connecter, mais c’est une décision de politique à prendre avec le propriétaire du réseau, pas une réparation à appliquer discrètement.

Lisez le journal du pair avant de changer à nouveau le client. Un rejet, une incompatibilité de politique et un abandon silencieux sont trois causes différentes qui ressemblent toutes à « connexion » sur l’écran du Mac.

Clients plus anciens et noyau 64 bits

L’ancien client Cisco IPSec charge une extension de noyau conçue pour les systèmes 32 bits et PowerPC. Sur un Mac démarré avec le noyau 64 bits, cette extension ne peut pas se charger, et le client échoue tôt avec l’erreur 51 parce qu’il n’atteint pas du tout le sous-système VPN. Aucun redémarrage du démon ne répare une extension de noyau dont l’architecture est mauvaise.

Recharger l’extension peut fonctionner un moment puis échouer de nouveau au démarrage suivant. Les réponses durables sont d’exécuter le noyau plus ancien là où il est encore pris en charge, ou de passer au client intégré fourni avec le système. Vérifiez l’architecture avant de consacrer une soirée à un client tiers qui ne peut pas se charger.

• Reproduisez une fois, puis vérifiez quel démon possède l’UDP 500 avant de toucher au profil.
• Lisez le premier échec après la phase 1 : une erreur de transmission pointe vers le socket local.
• Redémarrez la tâche launchd, pas seulement le processus, et confirmez que le port est libre.
• Essayez un second compte pour séparer une fenêtre de réauthentification côté serveur d’une panne du client.
• Notez l’architecture du noyau avant de blâmer le client.

Un VPN qui fonctionne exactement une fois est un problème d’état jusqu’à preuve du contraire. Nettoyer le démon est plus rapide que redémarrer, et cela préserve les preuves du journal qu’un redémarrage aurait jetées.