Paquets IKE en double : trouvez la transition manquante
Une requête IKE répétée est un événement de minuterie, pas un diagnostic. Construisez une chaîne de preuves de l'initiateur à la réponse, avec les bons identifiants de version.
Le journal montre deux fois la même requête IKE, quelqu'un pointe le lien montant mobile et le ticket se ferme sur une supposition. Cette supposition est le mythe : un paquet répété est une observation sur un échange, pas un diagnostic de lien. La retransmission est un comportement normal avec ses propres règles, et elle apparaît sur des chemins sains dès qu'une réponse est lente. Suivez la réponse avant d'accuser une interface.
Le mythe : une requête répétée prouve une perte sur un lien
Deux choses différentes produisent un doublon, et aucune ne désigne un coupable. Le demandeur peut répéter une requête faute de réponse, ou le point de capture peut montrer deux fois le même paquet selon l'endroit où il est attaché à la pile. Une sonde qui voit l'entrée et la sortie sur le même hôte enregistrera volontiers un paquet comme deux, et l'opérateur qui lit ce journal n'a aucun moyen de faire la différence sans les identifiants d'échange. Traitez le doublon comme un événement de minuterie tant que vous ne pouvez pas dire lequel des deux vous tenez.
Deux liens montants aggravent la confusion au lieu de la réduire. Une seule ligne de journal nomme une interface, alors que la réponse a pu sortir par l'autre, donc l'interface du message décrit où un paquet a été vu et non la forme de la conversation. C'est aussi pourquoi la première question est quel échange vous regardez, et non quel lien est défaillant.
Ce que la retransmission vous dit réellement
Dans IKEv2, la retransmission fonctionne ainsi : le demandeur répète une requête quand aucune réponse n'est arrivée, et le répondeur peut renvoyer sa réponse en cache au lieu d'en recalculer une. Les identifiants de message appartiennent à cet échange, et c'est ce qui rend une requête répétée avec le même identifiant reconnaissable comme le protocole qui fonctionne et non comme une nouvelle tentative. Une tentative initiale demande souvent plus qu'une adresse source ou un SPI d'initiateur pour être corrélée, donc l'enregistrement d'échange de la plateforme vaut mieux qu'une liste de paquets. IKEv1 suit des règles différentes avec d'autres identifiants, et un avertissement de fournisseur sur un premier paquet en double ne signifie pas la même chose selon les versions.
Ainsi, un horodatage de retransmission vous dit qu'une minuterie a expiré. Il ne vous dit pas quel saut était lent, et il ne vous dit certainement pas que l'opérateur est en faute. Ce sont des affirmations distinctes, et seule la seconde est utile dans un ticket.
La conséquence pratique est d'enregistrer l'échange avant de conclure. Notez l'adresse locale de réception, le chemin de réponse choisi par la politique, le tuple du pair et les identifiants de l'échange au même endroit, car chacun répond à une question différente quand l'enregistrement est relu plus tard.
Quatre points d'observation comme une seule chaîne
Considérez l'échange comme quatre maillons d'une chaîne plutôt que comme quatre endroits séparés où regarder. Un maillon porte une preuve ou reste inconnu, et la chaîne n'est informative que jusqu'à son maillon enregistré le plus faible. Le tableau ci-dessous est l'inventaire : ce que chaque position peut établir et ce qu'elle laisse intact.
| Position | Preuve qu'elle peut fournir | Ce qu'elle laisse ouvert |
|---|---|---|
| L'initiateur envoie | Une requête a quitté cet hôte | Si elle a atteint le pair |
| Le répondeur reçoit | La requête est arrivée | Si une réponse a été produite |
| Le répondeur envoie | Une réponse a quitté la passerelle | Si elle a suivi le chemin prévu |
| L'initiateur reçoit | L'échange est terminé | Si la politique a accepté le résultat |
Ne remplissez la chaîne que là où vous avez accès, et marquez le reste comme inconnu au lieu de l'inférer. Un point d'accroche qui enregistre des paquets sur une machine ne dit rien de ce que la machine distante a reçu, et une ligne de journal notant qu'une requête a été vue ne prouve pas qu'une réponse soit jamais partie. Des lacunes honnêtes sont plus utiles qu'un enregistrement d'apparence complète bâti sur des suppositions.
Trouvez la première transition manquante
Parcourez la chaîne depuis l'initiateur vers l'extérieur et arrêtez-vous au premier maillon sans preuve. Si la passerelle n'enregistre jamais la requête, la panne se situe sur le chemin avant elle. Quand la passerelle enregistre la même requête encore et encore tandis que le client n'enregistre jamais de réponse, la direction de retour est suspecte : adresse source, traduction et filtrage à chaque frontière que vous contrôlez. Si la réponse arrive et que le client ne progresse toujours pas, la question a quitté le transport et est devenue politique ou état.
Gardez le pair et le protocole fixes pendant la comparaison, et rappelez-vous que délai, perte, politique et état produisent chacun une chronologie différente. Un réseau mobile n'est pas automatiquement la cause, et une ligne fixe n'est pas automatiquement assez fiable pour toutes les exigences. Capturez les deux directions pendant que l'échange est actif :
tcpdump -ni any -vv 'udp port 500 or udp port 4500'Quand l'accès s'arrête avant l'extrémité distante, l'enregistrement aide encore s'il indique où il s'arrête. Une capture sur l'initiateur seul peut montrer une requête qui part et aucune réponse qui arrive, ce qui réduit la panne à tout ce qui suit ce point d'accroche sans prétendre savoir quel saut l'a laissée tomber. Marquez les maillons distants comme inconnus et laissez la personne suivante ayant accès les remplir. Rédigé ainsi, l'enregistrement reste honnête et toujours court.
Comparez avant de changer quoi que ce soit. Répéter la même requête vers le même pair avec le même protocole garde les variables dénombrables, tandis qu'une réinitialisation, un renouvellement de clé ou une modification de politique entre deux captures détruit la comparaison. Si un changement est inévitable, capturez de nouveau juste après pour que l'avant et l'après décrivent encore le même échange.
Ce que dit un rapport utile
Un rapport qui mérite une action associe une requête à sa réponse et nomme la première étape derrière laquelle il n'y a aucune preuve. Cette phrase survit à une lecture une semaine plus tard par un ingénieur qui n'était pas là, et elle donne à la personne suivante un point de départ plutôt qu'un suspect.
N'affaiblissez jamais les contrôles d'identité et n'élargissez pas l'ensemble de protocoles autorisé uniquement pour vérifier une théorie de retransmission. Sauvegardez les paquets et les enregistrements d'événements d'origine avant toute réinitialisation, car une réinitialisation détruit précisément le matériel que vous alliez collecter et efface la chronologie qui montrait où l'échange s'était bloqué.
Le mythe est qu'un doublon prouve que l'opérateur est en faute. La réalité est qu'un doublon prouve qu'une minuterie a expiré, et la réponse vit sur le chemin de réponse.