iPhone Always On VPN : deux tunnels peuvent partager une IP virtuelle

Sur un iPhone supervisé doté d’un profil Always On géré, le téléphone entretient un tunnel pour chaque interface IP active, si bien que le cellulaire et le Wi-Fi ont chacun le leur. Le serveur liste alors deux associations de sécurité IKE pour un seul appareil, souvent en partageant une adresse virtuelle, et le premier réflexe est d’appeler cela une boucle de rekey et de commencer à modifier les minuteurs. Ce réflexe est généralement faux. Suivez les étapes ci-dessous dans l’ordre où les preuves apparaissent sur le serveur, et laissez les réglages du téléphone tranquilles jusqu’à ce que le serveur vous dise dans quel cas vous êtes.

Commencez par les deux lignes que le serveur possède déjà

Listez les associations avec swanctl --list-sas et lisez quatre champs sur les deux entrées : l’adresse distante, l’identité authentifiée, l’IP virtuelle attribuée et l’heure de création. Deux adresses externes différentes avec une identité et une IP virtuelle, c’est la forme qui a lancé cette question, et cela vaut la peine de la noter avant toute modification. Vérifiez ensuite les associations enfants rattachées à chacune, car les sélecteurs de trafic décident si une recherche de destination pourrait un jour distinguer les deux tunnels. Une paire qui apparaît et disparaît en quelques secondes est un animal différent d’une paire dont les deux vivent des heures.

Triez la liste par heure de création avant de tirer une conclusion. La proximité dans la sortie ne veut rien dire, et un affichage tabulaire invite exactement à cette erreur.

Déterminez quel chevauchement vous regardez

Le rekey IKEv2 et la réauthentification make-before-break créent volontairement un bref chevauchement, en établissant la nouvelle association avant de supprimer l’ancienne. Les horodatages tranchent, car une ancienne SA qui disparaît une seconde ou deux après l’apparition de la nouvelle, c’est un renouvellement qui fait son travail. Les tunnels indépendants par interface n’ont jamais cette allure, puisque chacun persiste tant que son interface est active et que supprimer l’un ne découle pas de créer l’autre.

Le comportement Always On géré d’Apple est par interface, c’est pourquoi un appareil supervisé peut légitimement sembler plus occupé qu’un profil configuré à la main. Le bouton de connexion automatique d’une application de fournisseur n’implique pas la même chose, et une règle on-demand ordinaire non plus. La présentation du déploiement Apple décrit le modèle par interface ; comparez vos deux lignes avec elle avant de supposer une boucle. Les deux formes puisent aussi dans le même pool côté serveur, donc le chevauchement est votre seul signal précoce.

Voyez pourquoi une adresse virtuelle pour deux tunnels casse les réponses

Une réponse au téléphone est adressée à l’adresse interne, et le noyau choisit un tunnel sortant selon la destination et la politique, pas selon l’interface utilisée par le téléphone. Deux associations simultanées détenant la même IP virtuelle avec des politiques concordantes laissent la décision de routage sans moyen de dire à quelle session une réponse appartient. Certaines réponses prennent le mauvais tunnel, et le téléphone affiche une connexion qui fonctionne dans un sens ou qui meurt quand le Wi-Fi monte. Deux sorties de commandes prouvent l’état : swanctl --list-sas montrant la même IP virtuelle sur les deux SA, et ip xfrm policy montrant deux sélecteurs identiques.

C’est aussi cette paire de sorties que vous collez dans le registre des changements. Aucune des deux seule n’est convaincante, car chacune peut paraître plausible isolément.

Il s’agit d’adressage et de politique côté serveur, pas d’un mauvais comportement du téléphone, et aucun réglage client ne sépare deux adresses internes identiques. Le pool a distribué deux fois la même valeur et l’installateur de politiques l’a acceptée. Lisez le résultat du côté du serveur avant de blâmer le client.

Changez le pool ou le modèle de concurrence, pas le minuteur de rekey

Dans la configuration swanctl, l’unicité est une politique explicite sur la connexion : unique = replace supprime une connexion plus ancienne quand une nouvelle s’établit, et unique = keep rejette la nouvelle venue. Les deux valeurs agissent à l’établissement d’une connexion, pas sur les SA enfants qu’elle contient.

connections {
  ios-alwayson {
    unique = replace
  }
}

Aucune des deux valeurs n’est neutre pour un client par interface. keep rétablit un écran d’état propre en refusant le second tunnel et casse la conception gérée, tandis que replace démonte le tunnel plus ancien et constitue le même compromis dans l’autre sens. Si les deux tunnels sont réellement nécessaires, le backend du pool doit délivrer des baux distincts pour une identité, et sa clé de bail doit distinguer les demandes. Une table statique identité-adresse renverra volontiers deux fois la même adresse et reproduira le problème d’origine avec plus de configuration. Vérifiez comment le backend génère les clés de bail avant d’ajouter un second mappage statique.

Testez les transitions que vous déployez réellement

Sortez de portée du Wi-Fi avec une session active, puis revenez, et vérifiez que les réponses arrivent dans les deux sens. Faites-le deux fois, car la seconde transition est là où une politique obsolète apparaît généralement. Testez avec un service qui répond sur la connexion que vous avez ouverte, et répétez la sortie pendant que le tunnel porte du trafic au lieu de rester inactif. Un téléphone qui peut émettre mais pas recevoir paraît sain dans un journal de handshake et cassé dans un navigateur.

Un écran d’état réduit à une ligne n’est pas la preuve d’une conception qui fonctionne, seulement la preuve qu’un tunnel a disparu. Les deux sens doivent fonctionner avant qu’une transition passe. Notez ce que vous avez observé, avec les deux sorties du contrôle de chevauchement, pour que l’ingénieur suivant puisse comparer au lieu de refaire la promenade.