Como ler o primeiro intercambio IKEv2 nunha captura de paquetes

As capturas tomadas a metade de sesión son o motivo habitual de que unha traza IKEv2 pareza ruído, porque as partes xa están renovando claves ou intercambiando cargas cifradas cando comeza a gravación. Comeza mellor cun intento de conexión novo, de modo que a primeira mensaxe do ficheiro sexa a que abre a negociación. A orde de lectura seguinte presupón iso e marca o punto no que un paquete deixa de demostrar nada sobre o extremo remoto. Saltar ese paso é como un túnel que funciona acaba diagnosticado como un porto bloqueado.

Confirma que estás a ver o intercambio inicial

Unha negociación IKEv2 comeza con IKE_SA_INIT, tipo de intercambio 34, identificador de mensaxe 0. O iniciador escolle un SPI distinto de cero, e o SPI do respondedor é cero nesa primeira petición e distinto de cero na resposta. Eses tres feitos separan un intento novo dunha renovación de claves ou dunha mensaxe IKE_AUTH que casualmente está na parte superior dunha captura.

Os campos da cabeceira son lexibles, e tamén o son as cargas de proposta, intercambio de claves e nonce. Lexible non significa autenticado: ningunha das dúas partes demostrou identidade neste punto, e o valor privado de Diffie-Hellman nunca aparece no cable.

Imprime os campos como unha táboa en lugar de desprazarte por un panel de descodificación, porque as retransmisións e os SPI que non coinciden fanse evidentes en columnas.

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

Le a saída por parellas. Unha petición con identificador de mensaxe 0 seguida dunha resposta que leva o mesmo identificador e un SPI de respondedor distinto de cero é un só intercambio, mesmo cando aparece tres veces porque a petición se retransmitiu. Tres peticións idénticas non son tres inicios de sesión, e tratalas así é como se chega a concluír que un cliente está en bucle cando só é paciente. Ordena por identificador de mensaxe e logo por marca de tempo, e toda a conversa redúcese a unha lista curta de intentos.

Le un rexeitamento antes de ler un éxito

Unha resposta non é automaticamente un avance. O respondedor pode contestar cunha notificación cookie e esperar que o iniciador o intente de novo, ou cun INVALID_KE_PAYLOAD nomeando un grupo que aceptaría no seu lugar. Ambas chegan como mensaxes IKE ben formadas, e ambas parecen un intercambio rematado a un filtro que só conta paquetes.

Abre a carga de notificación e le o tipo antes que nada. Un desafío cookie significa que o respondedor se defende de enderezos de orixe falsificados, e o cliente debe reenviar coa cookie anexa. Un grupo non válido significa que as dúas propostas non coinciden, e ningunha cantidade de reintentos o cambiará ata que se mova a configuración dunha das partes.

Só IKE_AUTH, o segundo intercambio, transporta a identidade cifrada e as cargas de autenticación. Por tanto, un IKE_SA_INIT completado dinos que as partes coinciden en algoritmos e claves derivadas, e absolutamente nada sobre se se aceptarán as credenciais. Espera tamén dúas mensaxes alí, e espera que ambas sexan opacas sen as claves de sesión.

O porto 4500 non é un só protocolo

O UDP 500 adoita levar o intercambio inicial. Unha vez executada a detección de NAT, IKE pasa ao 4500 e antepón a cada mensaxe un marcador de catro bytes a cero que non é ESP. O ESP encapsulado no mesmo porto comeza pola contra cun SPI de ESP distinto de cero, e un keepalive de NAT dun só byte é unha terceira forma que aparece cando non ocorre nada máis.

Un filtro que coincide só co porto mestura as tres cousas, e por iso "hai tráfico no 4500" resolve tan pouco. Divide a vista por protocolo antes de concluír nada sobre o extremo remoto.

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

O silencio describe o punto de observación

As peticións sen respostas establecen exactamente unha cousa: naquel punto de captura non apareceu ningunha resposta. O filtrado, unha ruta que envía a resposta a outro sitio, un respondedor inalcanzable ou un respondedor ao que non lle gusta a proposta producen todos o mesmo resultado baleiro, e unha sonda UDP xenérica non os separará.

Un ICMP inalcanzable é unha evidencia doutro tipo. Le o paquete citado que contén e identifica que dispositivo o emitiu, porque o rexeitamento administrativo dun encamiñador non é un erro autenticado do extremo remoto.

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

Correlaciona o mesmo intento cos rexistros do servidor onde che permitan lelos. Chegou a petición, respondeu o servizo e onde se detivo a resposta? Eses tres respostas lévanche a un problema de ruta ou a un problema de política, e custan menos que rotar as credenciais por cuarta vez.