Como ler a primeira troca IKEv2 numa captura de pacotes

As capturas feitas a meio de uma sessão são a razão habitual para um rasto IKEv2 parecer ruído, porque as partes já estão a renovar chaves ou a trocar cargas cifradas quando a gravação começa. Comece antes por uma nova tentativa de ligação, para que a primeira mensagem do ficheiro seja a que abre a negociação. A ordem de leitura abaixo pressupõe isso e marca o ponto em que um pacote deixa de provar seja o que for sobre o extremo remoto. Saltar esse passo é como um túnel a funcionar acaba diagnosticado como uma porta bloqueada.

Confirme que está a ver a troca inicial

Uma negociação IKEv2 começa com IKE_SA_INIT, tipo de troca 34, identificador de mensagem 0. O iniciador escolhe um SPI diferente de zero, e o SPI do respondedor é zero nesse primeiro pedido e diferente de zero na resposta. Estes três factos separam uma tentativa nova de uma renovação de chaves ou de uma mensagem IKE_AUTH que por acaso está no topo de uma captura.

Os campos do cabeçalho são legíveis, e também o são as cargas de proposta, troca de chaves e nonce. Legível não significa autenticado: nenhuma das partes provou identidade neste ponto, e o valor privado de Diffie-Hellman nunca aparece no fio.

Imprima os campos como tabela em vez de percorrer um painel de descodificação, porque retransmissões e SPI que não coincidem tornam-se óbvios em colunas.

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

Leia a saída aos pares. Um pedido com identificador de mensagem 0 seguido de uma resposta que leva o mesmo identificador e um SPI de respondedor diferente de zero é uma só troca, mesmo quando aparece três vezes porque o pedido foi retransmitido. Três pedidos idênticos não são três inícios de sessão, e tratá-los assim é como se conclui que um cliente está em ciclo quando apenas é paciente. Ordene por identificador de mensagem e depois por marca temporal, e toda a conversa se reduz a uma lista curta de tentativas.

Leia uma rejeição antes de ler um sucesso

Uma resposta não é automaticamente progresso. O respondedor pode responder com uma notificação cookie e esperar que o iniciador tente de novo, ou com INVALID_KE_PAYLOAD indicando um grupo que aceitaria em vez daquele. Ambas chegam como mensagens IKE bem formadas, e ambas parecem uma troca terminada a um filtro que só conta pacotes.

Abra a carga de notificação e leia o tipo antes de tudo o resto. Um desafio cookie significa que o respondedor se defende de endereços de origem falsificados, e o cliente tem de reenviar com o cookie anexado. Um grupo inválido significa que as duas propostas não concordam, o que nenhuma quantidade de novas tentativas altera enquanto a configuração de um dos lados não mudar.

Só IKE_AUTH, a segunda troca, transporta a identidade cifrada e as cargas de autenticação. Um IKE_SA_INIT concluído diz-lhe portanto que as partes concordam nos algoritmos e nas chaves derivadas, e absolutamente nada sobre se as credenciais serão aceites. Espere também duas mensagens ali, e espere que ambas sejam opacas sem as chaves de sessão.

A porta 4500 não é um só protocolo

O UDP 500 transporta normalmente a troca inicial. Uma vez executada a deteção de NAT, o IKE passa para a 4500 e antepõe a cada mensagem um marcador nulo de quatro bytes que não é ESP. O ESP encapsulado na mesma porta começa, ao contrário, com um SPI de ESP diferente de zero, e um keepalive de NAT de um único byte é uma terceira forma que aparece quando não acontece mais nada.

Um filtro que só corresponde à porta mistura as três coisas, e é por isso que "há tráfego na 4500" resolve tão pouco. Separe a vista por protocolo antes de concluir algo 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 silêncio descreve o ponto de observação

Pedidos sem respostas estabelecem exatamente uma coisa: naquele ponto de captura não apareceu qualquer resposta. A filtragem, uma rota que envia a resposta para outro sítio, um respondedor inalcançável ou um respondedor que não gosta da proposta produzem todos o mesmo resultado vazio, e uma sonda UDP genérica não os separará.

Um ICMP inalcançável é uma evidência de outro tipo. Leia o pacote citado lá dentro e identifique que equipamento o emitiu, porque a rejeição administrativa de um encaminhador não é um erro autenticado do extremo remoto.

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

Correlacione a mesma tentativa com os registos do lado do servidor onde lhe for permitido lê-los. O pedido chegou, o serviço respondeu e onde parou a resposta? Essas três respostas enviam-no para um problema de caminho ou para um problema de política, e custam menos do que rodar as credenciais uma quarta vez.