Comment lire le premier échange IKEv2 dans une capture de paquets

Les captures prises en cours de session sont la raison habituelle pour laquelle une trace IKEv2 ressemble à du bruit, car les pairs renouvellent déjà des clés ou échangent des charges chiffrées quand l'enregistrement commence. Partez plutôt d'une nouvelle tentative de connexion, afin que le premier message du fichier soit celui qui ouvre la négociation. L'ordre de lecture ci-dessous suppose cela et marque le point où un paquet cesse de prouver quoi que ce soit sur l'extrémité distante. Sauter cette étape, c'est ainsi qu'un tunnel qui fonctionne finit diagnostiqué comme un port bloqué.

Vérifiez que vous regardez l'échange d'ouverture

Une négociation IKEv2 commence par IKE_SA_INIT, type d'échange 34, identifiant de message 0. L'initiateur choisit un SPI non nul, et le SPI du répondeur est nul dans cette première requête et non nul dans la réponse. Ces trois faits séparent une nouvelle tentative d'un renouvellement de clés ou d'un message IKE_AUTH qui se trouve en tête d'une capture.

Les champs d'en-tête sont lisibles, tout comme les charges de proposition, d'échange de clés et de nonce. Lisible ne veut pas dire authentifié : aucun des deux pairs n'a prouvé son identité à ce stade, et la valeur privée Diffie-Hellman n'apparaît jamais sur le fil.

Imprimez les champs sous forme de tableau plutôt que de faire défiler un volet de décodage, car les retransmissions et les SPI discordants deviennent évidents en colonnes.

tshark -r ike.pcapng -Y "isakmp" -T fields -e frame.number -e ip.src -e udp.srcport -e isakmp.exchangetype -e isakmp.messageid -e isakmp.initiator_spi -e isakmp.responder_spi

Lisez la sortie par paires. Une requête avec l'identifiant de message 0 suivie d'une réponse portant le même identifiant et un SPI de répondeur non nul forment un seul échange, même lorsqu'elles apparaissent trois fois parce que la requête a été retransmise. Trois requêtes identiques ne sont pas trois connexions, et les traiter comme telles est la façon dont on conclut qu'un client boucle alors qu'il est seulement patient. Triez par identifiant de message, puis par horodatage, et toute la conversation se réduit à une courte liste de tentatives.

Lisez un rejet avant de lire un succès

Une réponse n'est pas automatiquement un progrès. Le répondeur peut répondre par une notification cookie et attendre que l'initiateur réessaie, ou par INVALID_KE_PAYLOAD nommant un groupe qu'il accepterait à la place. Les deux arrivent comme des messages IKE bien formés, et les deux ressemblent à un échange terminé pour un filtre qui ne compte que les paquets.

Ouvrez la charge de notification et lisez le type avant toute autre chose. Un défi cookie signifie que le répondeur se défend contre des adresses sources usurpées, et le client doit renvoyer avec le cookie joint. Un groupe invalide signifie que les deux propositions ne concordent pas, ce qu'aucune quantité de nouvelles tentatives ne changera tant que la configuration d'un côté ne bouge pas.

Seul IKE_AUTH, le second échange, transporte l'identité chiffrée et les charges d'authentification. Un IKE_SA_INIT terminé vous dit donc que les pairs s'accordent sur les algorithmes et les clés dérivées, et absolument rien sur l'acceptation des identifiants. Attendez-vous aussi à deux messages à cet endroit, et à ce que les deux soient opaques sans les clés de session.

Le port 4500 n'est pas un seul protocole

UDP 500 transporte généralement l'échange d'ouverture. Une fois la détection NAT exécutée, IKE passe sur 4500 et préfixe chaque message d'un marqueur nul de quatre octets qui n'est pas ESP. L'ESP encapsulé sur le même port commence au contraire par un SPI ESP non nul, et un keepalive NAT d'un seul octet est une troisième forme qui apparaît quand rien d'autre ne se passe.

Un filtre qui ne correspond qu'au port mélange les trois, et c'est pourquoi « il y a du trafic sur 4500 » tranche si peu. Séparez la vue par protocole avant de conclure quoi que ce soit sur l'extrémité distante.

tshark -r ike.pcapng -Y "udp.port == 4500 && isakmp" -T fields -e frame.number -e isakmp.exchangetype
tshark -r ike.pcapng -Y "udp.port == 4500 && !isakmp" -T fields -e frame.number -e esp.spi

Le silence décrit le point d'observation

Les requêtes sans réponse établissent exactement une chose : à ce point de capture, aucune réponse n'est apparue. Le filtrage, une route qui envoie la réponse ailleurs, un répondeur injoignable ou un répondeur qui n'aime pas la proposition produisent tous le même résultat vide, et une sonde UDP générique ne les distinguera pas.

Un ICMP inatteignable est une preuve d'un autre genre. Lisez le paquet cité à l'intérieur et identifiez quel équipement l'a émis, car le rejet administratif d'un routeur n'est pas une erreur authentifiée de l'extrémité distante.

tshark -r ike.pcapng -Y "icmp.type == 3" -T fields -e frame.number -e ip.src -e icmp.code

Corrélez la même tentative avec les journaux côté serveur là où vous êtes autorisé à les lire. La requête est-elle arrivée, le service a-t-il répondu, et où la réponse s'est-elle arrêtée ? Ces trois réponses vous envoient vers un problème de chemin ou vers un problème de politique, et elles coûtent moins qu'une quatrième rotation des identifiants.