IKEv2 não é um único handshake: IKE SA, autenticação e depois CHILD SA

Pode pensar que uma ligação IKEv2 é uma única troca que termina com o seu tráfego cifrado. São pelo menos duas, e a primeira não autentica ninguém. Os pares começam com mensagens de controlo, acordam parâmetros criptográficos, provam a identidade e só depois negoceiam o estado que transporta os pacotes da aplicação. É essa ordem que explica a discrepância que as pessoas relatam constantemente: o gateway responde, o cliente diz ligado, e a aplicação privada continua a expirar. Eis o que cada fase faz realmente e o que deve ser verdade depois dela.

O mito: se o gateway responde, está ligado

Uma resposta à primeira mensagem prova que o extremo é alcançável e está disposto a falar. Não prova que uma conta foi aceite, que uma cadeia de certificados foi validada, nem que alguma política de dados foi instalada.

Essas falhas acontecem mais tarde e produzem sintomas diferentes. A rejeição de um certificado ou uma falha de EAP chega depois de a primeira troca já ter sido bem-sucedida, e é por isso que um ping ao UDP 500 e um ícone verde no cliente dizem tão pouco.

IKE_SA_INIT: acordar parâmetros, não identidade

A primeira troca transporta as propostas para a associação de segurança IKE: algoritmos de cifra e integridade, uma função pseudoaleatória e um grupo Diffie-Hellman. Os pares trocam também nonces, e cada lado deriva o material de chaves para a IKE SA a partir do segredo partilhado que esses valores produzem. Nada nesta troca estabelece quem é a outra parte. Estabelece apenas que ambos os lados conseguem calcular as mesmas chaves e que concordam numa proposta. Um respondedor a quem nenhuma proposta agrada rejeita aqui a troca, e é por isso que uma incompatibilidade de versão ou de algoritmo parece um servidor em baixo.

A IKE SA criada neste ponto protege todas as trocas de gestão posteriores. É esse o seu trabalho, e é um trabalho diferente de proteger os seus pacotes.

IKE_AUTH: provar a identidade e depois construir o primeiro CHILD SA

A segunda troca transporta a identidade. Com certificados, cada par assina com a sua chave privada e apresenta uma cadeia que o outro tem de validar; com EAP, o respondedor desafia o iniciador através do método escolhido. É aqui que um nome de servidor errado, um certificado expirado ou uma palavra-passe rejeitada finalmente aparecem.

Normalmente o IKE_AUTH negocia também o primeiro CHILD SA, pelo que a proteção de dados é acordada na mesma ida e volta. O iniciador propõe seletores de tráfego, o respondedor estreita-os ou rejeita-os, e as chaves do caminho de dados derivam da IKE SA. Isso significa que uma só troca pode falhar em dois sítios muito diferentes: identidade ou política. Leia o payload de notificação ou o erro em vez da falha genérica de handshake, porque a correção de um é um certificado e a do outro é uma divergência de sub-rede.

Duas SA, dois trabalhos

Mantê-las separadas explica dois comportamentos que parecem erros. Um túnel pode aparecer estabelecido enquanto uma renovação de chaves falha em segundo plano, e um CHILD SA pode ser substituído sem que o cliente perca a ligação.

No strongSwan, a referência de configuração do IKEv2 e o swanctl --list-sas mostram os dois níveis, e ip xfrm state mais ip xfrm policy mostram o que o núcleo instalou realmente. Comparar essas duas vistas é a forma mais rápida de ver se a negociação terminou ou se apenas pareceu terminar. Se o daemon lista um CHILD SA para o qual o núcleo não tem estado, a instalação falhou em silêncio. Se o núcleo mantém estado que o daemon não conhece, está a ver um resto de uma tentativa anterior.

O que ainda tem de ser verdade depois de o túnel subir

Os seletores de tráfego definem que endereços estão cobertos. Se o cliente propõe uma sub-rede e o servidor espera outra, o CHILD SA instala-se mas não transporta nada de útil, e o erro aparece como um problema de encaminhamento e não de negociação. Depois a pilha local tem de colaborar: reencaminhamento ativo onde o anfitrião encaminha, rotas a apontar para o túnel, regras de firewall que permitem os pacotes desencapsulados e um resolvedor interno se nomes privados estiverem envolvidos. Cada um destes falha separadamente e nenhum é corrigido reiniciando o daemon IKE.

Mantenha o registo visível enquanto diagnostica: a troca inicial, depois a validação de identidade, a seguir a autenticação de utilizador onde se aplica, depois a instalação do CHILD e por fim o tráfego de aplicação. A fase que para é a fase a corrigir, e uma falha de encaminhamento posterior nunca é razão para relaxar as verificações de identidade que já passaram.