La même identité IKEv2 sur deux iPhone ? Ils se connectent à tour de rôle
Un profil copié sur deux appareils donne à la passerelle un seul peer au lieu de deux. Observez la table des peers se remplir et se vider, puis attribuez une valeur par appareil.
Deux téléphones, un profil et un schéma qui semble surnaturel jusqu’à ce que quelqu’un regarde la passerelle. Un appareil garde le tunnel, le second se connecte, et le premier le perd en quelques secondes. Le premier se reconnecte et le second tombe. L’économie de batterie, l’itinérance Wi-Fi et le NAT de l’opérateur sont blâmés, alors que la vraie cause se trouve dans un champ texte copié avec tout le reste. IKEv2 identifie un peer par un nom, et les deux téléphones présentent le même.
L’identité est la clé sous laquelle le serveur te range
Dans un échange IKEv2, chaque partie déclare qui elle est : l’initiateur envoie un identifiant local, le répondeur répond avec le sien, et le répondeur vérifie aussi l’identité revendiquée par l’initiateur au regard de la politique. La passerelle conserve son état par identité plutôt que par appareil, car un appareil n’est pas une chose qu’elle peut voir. Deux téléphones dotés d’un seul identifiant arrivent donc comme un seul peer, et le second échange doit écraser le premier. Le problème n’apparaît que lorsque les deux sont utilisés, et c’est pourquoi un test avec un seul téléphone ne le reproduit jamais.
Rien de tout cela n’est un défaut du client. Le client a envoyé exactement ce que le profil lui disait d’envoyer.
À quoi ressemble la collision depuis la passerelle
Regardez la liste des peers pendant que les deux téléphones sont éveillés et utilisés. Une collision affiche une seule entrée dont l’adresse change à mesure que les téléphones permutent, et le compteur de sessions actives n’atteint jamais deux. Le démontage à la demande a une autre allure, et les distinguer demande une observation plutôt qu’une théorie.
| Observation | Shared identity | Idle teardown |
|---|---|---|
| Peer entries while both are awake | One, with a changing address | One per phone, or none |
| What triggers the drop | The other device connecting | Time without traffic |
| What restores it | The other device disconnecting | Any app needing the tunnel |
Notez les deux événements avec des horodatages pendant que cela se produit. Une coupure qui coïncide avec la connexion de l’autre combiné pointe vers l’identifiant, et une coupure qui arrive un intervalle d’inactivité après le dernier paquet pointe vers un minuteur.
D’où viennent les doublons
Exporter une configuration qui fonctionne et ne modifier que l’adresse du serveur produit un second fichier où l’identité du premier est encore présente. C’est le chemin ordinaire vers cette panne, et cela arrive généralement lors de l’intégration pressée d’un petit groupe.
Les noms des champs rendent l’oubli facile. L’identifiant distant nomme la passerelle que le téléphone attend, et le copier est correct. L’identifiant local nomme ce combiné auprès de la passerelle, et copier cette valeur est tout le problème.
Attribuez une valeur par appareil
Utilisez quelque chose d’unique pour le combiné et de stable pendant toute sa durée de vie, comme l’identifiant d’appareil de l’inventaire ou une valeur que votre système de gestion génère à chaque enrôlement. Une étiquette de service, un nom de compte de service partagé ou l’adresse e-mail de l’utilisateur entrent tous en collision dès que cette personne a un second appareil.
Générez la charge utile par appareil au lieu de distribuer un seul fichier. Notez quelle valeur appartient à quel combiné, afin qu’un remplacement ne restaure pas l’ancien profil et ne replace pas le nouveau téléphone directement dans la même collision.
Vérifiez aussi le côté serveur. Une passerelle qui associe l’identité à une adresse de tunnel fixe peut encore entrer en collision lorsque deux identifiants différents reçoivent la même attribution, alors confirmez que le pool a de la place et que les attributions ne sont pas épinglées par utilisateur.
Vérifiez avec les deux téléphones éveillés
Connectez le premier, atteignez une ressource privée, puis connectez le second et laissez les deux inactifs une minute. Les deux sessions devraient persister et la liste des peers devrait montrer deux identités. Verrouillez et déverrouillez ensuite chaque téléphone pour confirmer que le cas d’inactivité se comporte toujours bien.
Si une seule session tombe encore une fois par jour sans que rien d’autre ne se connecte, l’identité n’est plus le suspect. Passez aux minuteurs d’inactivité et aux limites de session du serveur au lieu de modifier à nouveau le profil.