Comment lire un échange IKE_SA_INIT récent dans une capture

Partez d’une capture qui commence avant le premier paquet de la tentative, sinon vous lirez le milieu d’une conversation. Une négociation déjà en cours montre des échanges chiffrés et des renouvellements de clés, et ni l’un ni l’autre ne ressemble à l’ouverture. L’ouverture est la partie que vous pouvez décoder sans clés, et c’est pourquoi elle répond si bien aux questions d’accessibilité. Quatre contrôles dans l’ordre vous mènent d’une capture fraîche à une affirmation défendable sur le côté qui a cessé de parler.

D’abord, vérifiez que la capture commence au début

Une capture démarrée après la montée du tunnel contiendra le flux de données encapsulé et des keepalives périodiques, et les deux sont soit chiffrés, soit presque vides. Redémarrez le client et enregistrez la tentative elle-même, ou déclenchez délibérément une nouvelle connexion pendant que la capture tourne. Si vous ne pouvez pas produire une tentative fraîche, notez-le, car aucun décodage ne récupère une ouverture que vous n’avez jamais enregistrée.

Limitez la capture aux deux extrémités et à UDP 500 et 4500 pour que le fichier reste assez petit pour être lu. Sur un hôte chargé, une capture sans filtre enterre la négociation sous un trafic sans rapport.

tcpdump -i any -n -s 0 -w fresh-ike.pcap 'udp port 500 or udp port 4500'

Conservez le fichier quand la tentative est intéressante, car la même capture répond aux deux questions suivantes : ce qu’était l’échange, et si quelque chose est revenu. Étiquetez-le avec l’heure de début et la paire d’extrémités sur laquelle vous avez filtré. Une capture sans ces deux faits est inutile une semaine plus tard, quand les adresses ont changé et que personne ne se souvient quelle tentative elle a enregistrée.

Ensuite, lisez l’en-tête avant les charges utiles

L’en-tête IKE porte les index de paramètres de sécurité, le type d’échange et l’ID de message, et lors d’une négociation fraîche ces valeurs sont distinctives. L’initiateur invente un SPI non nul, la requête initiale porte un SPI de répondeur nul car aucune réponse n’a encore été vue, le type d’échange est IKE_SA_INIT et l’ID de message est nul. Tout le reste appartient à une étape ultérieure de la même négociation ou à une tentative entièrement différente.

Les charges de proposition, d’échange de clés et de nonce de ce premier échange sont lisibles en clair. Lisible ne veut pas dire authentifié, et à ce stade aucune des deux parties n’a prouvé son identité.

La valeur privée Diffie-Hellman ne traverse jamais le câble, donc la capture ne vous permet pas de dériver des clés de session. L’authentification a lieu dans l’échange suivant, protégée par ce que le premier a négocié. Si quelqu’un demande si une extrémité est authentique, cet échange ne peut pas répondre à cette question. Il peut seulement montrer que les deux côtés se sont mis d’accord sur une proposition et ont produit un secret partagé que le fichier ne contient pas.

Troisièmement, associez la requête à sa réponse

Associez sur la paire de SPI, le type d’échange et l’ID de message, puis vérifiez l’indicateur de réponse. Une retransmission répète l’ID de message de l’original et n’est pas une seconde tentative de connexion. Compter les paquets au lieu des échanges, c’est ainsi qu’une négociation saine devient une boucle fantôme.

Une réponse peut aussi être un refus : une demande de cookie, une notification de groupe inacceptable ou une erreur au sujet d’une proposition. Ce sont des réponses légitimes, et elles signifient que le chemin fonctionne alors que la politique ne fonctionne pas. Décodez la notification au lieu de traiter chaque réponse comme un succès. Quand la notification nomme un groupe ou une proposition, la réparation est du côté de la configuration et non au pare-feu.

Le sens compte aussi. Une requête sans réponse et une réponse qui n’atteint jamais le client sont deux pannes différentes, et seule la seconde ressemble à un délai dépassé côté client.

Quatrièmement, séparez IKE de tout le reste sur 4500

Le port 4500 porte trois choses qui se ressemblent dans une vue résumée : IKE derrière un marqueur non-ESP nul de quatre octets, de l’ESP encapsulé dont la position du marqueur contient un SPI non nul, et de courts keepalives. C’est ce marqueur qui sépare IKE de l’ESP encapsulé, alors lisez ces octets avant d’étiqueter le trafic comme IKE. Une étiquette de capture qui lit 4500 est un numéro de port, pas un protocole.

L’ESP encapsulé est une charge chiffrée que vous ne pouvez pas interpréter sans clés, et sa présence peut être le signe d’un tunnel qui fonctionne plutôt qu’une panne.

Surveillez les deux ports pour la même tentative, car IKE peut passer sur 4500 après la détection NAT alors qu’il s’est ouvert sur 500. Une trace filtrée seulement sur 500 paraît silencieuse précisément quand la négociation a réussi et s’est déplacée. Élargissez le filtre et relisez la même fenêtre temporelle avant de tirer la moindre conclusion d’une absence.

Ce que signifie le silence à un point d’observation

L’absence de réponse chez le client ne prouve que ce que ce point a observé. Le filtrage, le routage, la mauvaise adresse distante, un service arrêté et une incompatibilité de protocole produisent tous la même trace vide.

Un ICMP unreachable pertinent ajoute une preuve, mais lisez le paquet cité à l’intérieur et notez l’adresse de l’appareil qui l’a émis.

Le rejet d’un routeur est un événement différent d’une erreur authentifiée renvoyée par l’extrémité, et seule la seconde prouve que le service est vivant. Corrélez la même tentative avec les journaux du serveur ou une observation approuvée pour savoir si la requête est arrivée et si une réponse est sortie. Gardez les captures limitées et privées, car des champs de poignée de main lisibles ne rendent pas le reste du fichier inoffensif. Le résultat qui vaut la peine est une requête et une réponse appariées, ou un manque documenté avec un point d’observation nommé.