Com llegir el primer intercanvi IKEv2 en una captura de paquets

Les captures fetes a mig camí d'una sessió són la raó habitual per la qual una traça IKEv2 sembla soroll, perquè les parts ja estan renovant claus o intercanviant càrregues xifrades quan comença l'enregistrament. Comença en canvi amb un intent de connexió nou, de manera que el primer missatge del fitxer sigui el que obre la negociació. L'ordre de lectura següent ho pressuposa i marca el punt en què un paquet deixa de demostrar res sobre l'extrem remot. Saltar aquest pas és com un túnel que funciona s'acaba diagnosticant com un port bloquejat.

Confirma que estàs mirant l'intercanvi inicial

Una negociació IKEv2 comença amb IKE_SA_INIT, tipus d'intercanvi 34, identificador de missatge 0. L'iniciador tria un SPI diferent de zero, i l'SPI del responedor és zero en aquesta primera petició i diferent de zero en la resposta. Aquests tres fets separen un intent nou d'una renovació de claus o d'un missatge IKE_AUTH que casualment és al capdamunt d'una captura.

Els camps de la capçalera són llegibles, i també ho són les càrregues de proposta, intercanvi de claus i nonce. Llegible no vol dir autenticat: cap de les dues parts no ha demostrat la seva identitat en aquest moment, i el valor privat de Diffie-Hellman no apareix mai al fil.

Imprimeix els camps com una taula en lloc de fer scroll per un panell de descodificació, perquè les retransmissions i els SPI que no coincideixen es fan evidents en columnes.

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

Llegeix la sortida per parelles. Una petició amb identificador de missatge 0 seguida d'una resposta que porta el mateix identificador i un SPI de responedor diferent de zero és un sol intercanvi, encara que aparegui tres vegades perquè la petició s'ha retransmès. Tres peticions idèntiques no són tres inicis de sessió, i tractar-les així és com s'arriba a concloure que un client està en bucle quan només és pacient. Ordena per identificador de missatge i després per marca de temps, i tota la conversa es redueix a una llista curta d'intents.

Llegeix un rebuig abans de llegir un èxit

Una resposta no és automàticament un avenç. El responedor pot contestar amb una notificació cookie i esperar que l'iniciador ho torni a provar, o amb INVALID_KE_PAYLOAD indicant un grup que acceptaria en lloc d'aquell. Totes dues arriben com a missatges IKE ben formats, i totes dues semblen un intercanvi acabat a un filtre que només compta paquets.

Obre la càrrega de notificació i llegeix el tipus abans que res. Un repte cookie vol dir que el responedor es defensa d'adreces d'origen falsificades, i el client ha de tornar a enviar amb la cookie adjunta. Un grup no vàlid vol dir que les dues propostes no coincideixen, i cap quantitat de reintents ho canviarà fins que es mogui la configuració d'una de les parts.

Només IKE_AUTH, el segon intercanvi, porta la identitat xifrada i les càrregues d'autenticació. Per tant, un IKE_SA_INIT complet et diu que les parts coincideixen en algorismes i claus derivades, i absolutament res sobre si s'acceptaran les credencials. Espera també dos missatges allà, i espera que tots dos siguin opacs sense les claus de sessió.

El port 4500 no és un sol protocol

L'UDP 500 sol portar l'intercanvi inicial. Un cop s'ha executat la detecció de NAT, IKE passa al 4500 i posa davant de cada missatge un marcador de quatre bytes a zero que no és ESP. L'ESP encapsulat al mateix port comença en canvi amb un SPI d'ESP diferent de zero, i un keepalive de NAT d'un sol byte és una tercera forma que apareix quan no passa res més.

Un filtre que només coincideix amb el port barreja les tres coses, i per això "hi ha trànsit al 4500" resol tan poc. Divideix la vista per protocol abans de concloure res sobre l'extrem remot.

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

El silenci descriu el punt d'observació

Les peticions sense resposta estableixen exactament una cosa: en aquell punt de captura no va aparèixer cap resposta. El filtratge, una ruta que envia la resposta a un altre lloc, un responedor inabastable o un responedor a qui no li agrada la proposta produeixen tots el mateix resultat buit, i una sonda UDP genèrica no els separarà.

Un ICMP inabastable és una evidència d'un altre tipus. Llegeix el paquet citat que hi ha dins i identifica quin dispositiu el va emetre, perquè el rebuig administratiu d'un encaminador no és un error autenticat de l'extrem remot.

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

Correlaciona el mateix intent amb els registres del servidor allà on et permetin llegir-los. Va arribar la petició, va respondre el servei i on es va aturar la resposta? Aquestes tres respostes et porten a un problema de camí o a un problema de política, i costen menys que rotar les credencials per quarta vegada.