ESP de saída sem resposta não significa que a VPN está morta
O ESP protege uma direção por associação e não confirma nada. Alinhe a conversa interna e a SA de entrada antes de chamar o servidor de sem resposta.
Capturou tráfego no anfitrião IPsec, viu pacotes ESP sair, não viu nada voltar e concluiu que o lado remoto está avariado. A captura não sustenta essa conclusão. O ESP protege uma direção de uma conversa e não confirma nada na camada IP, pelo que a ausência de ESP de retorno pode significar que a aplicação não tinha nada a dizer, tão facilmente como pode significar que o túnel está morto. Leia a troca interna e o estado do lado recetor antes de culpar qualquer extremidade.
O mito: cada pacote protegido ganha uma resposta
O ESP não é um protocolo de pedido e resposta. Cifra e autentica o que a política selecionar, e o recetor valida, decifra e entrega esse pacote interno sem gerar um pacote próprio. Um pedido UDP que o destino ignora, ou um eco ICMP que a política de entrada descarta, produz silêncio em ambos os sentidos como resultado correto. Tratar esse silêncio como falha de transporte leva-o a procurar uma avaria de rede que nunca existiu.
O que uma captura unilateral prova de facto é que a pilha do emissor cifrou algo naquele ponto de observação. Nada sobre a chegada, e nada sobre a intenção de responder. A pergunta útil não é „porque não há resposta“ mas „o que deveria a conversa interna ter produzido“.
Duas SA, dois SPI, uma conversa
As associações de segurança IPsec são unidirecionais, pelo que uma troca protegida normal executa uma associação de entrada e uma associação de saída com identificadores separados e estado independente. Procurar o tráfego de retorno pelo SPI do pacote de saída é, por isso, um erro de categoria, porque qualquer resposta viaja sob a própria SA de saída do par com o seu próprio SPI. Emparelhe antes pelo conjunto de seletores de tráfego e pelos endereços do par.
A renegociação da chave complica o quadro durante alguns segundos, porque o estado antigo e o de substituição podem sobrepor-se. Se o sintoma começou por volta de uma renegociação, recolha os identificadores das associações e os carimbos temporais em conjunto e não apenas o nome da ligação.
O que o recetor tem de fazer antes de algo responder
| Stage | What to look at | Wrong conclusion if skipped |
|---|---|---|
| Sender encrypts | outbound SA packet counter | "the tunnel is up" |
| Peer receives | inbound SA counter and replay window | "the peer is down" |
| Inner delivery | target host or service logs | "routing is broken" |
| Application replies | the app's own trace | "the reply was dropped" |
| Protected return | the peer's outbound SA | "ESP only works one way" |
Cada linha falha de forma independente e cada falha tem um responsável diferente, razão pela qual uma única captura não as consegue distinguir. O contador de entrada é a única prova direta da chegada, porque um pacote que falhe a autenticação ou a verificação de repetição é descartado sem qualquer resposta. Um par cujo contador de entrada não se moveu não lhe está a dar informação nenhuma sobre a sua política.
A entrega é um passo separado da decifragem. O estado pode ser válido e o pacote ainda assim ser descartado depois por uma política de entrada ou por uma rota que não inclua o destino interno, pelo que verifique se o anfitrião de destino viu texto simples em vez de assumir que um contador limpo significa que o pacote foi para onde queria.
O ESP nativo não é UDP
O ESP nativo é o protocolo IP 50, que não é TCP nem UDP e não tem portas nenhumas. Uma regra de firewall que permita IKE em UDP 500 não diz, por isso, nada sobre o caminho de dados, e um filtro escrito em torno de portas pode deixar um túnel negociar e depois descartar tudo o que é transportado dentro dele. Teste o caminho de dados à parte, no modo que realmente observou.
Atrás de NAT a forma muda: a carga protegida viaja dentro de UDP, habitualmente na porta 4500, como define a RFC 3948. Registe o modo ativo antes de escrever qualquer regra, porque um dispositivo no caminho pode tratar o ESP nativo e o ESP encapsulado em UDP de forma completamente diferente, e algumas caixas intermédias permitem um enquanto descartam o outro.
Leia contadores que pertencem a este incidente
Num anfitrião strongSwan, swanctl --list-sas reporta contadores de pacotes e bytes por associação nos dois sentidos, o que basta para separar „nunca chegou“ de „chegou e não foi respondido“. No Linux, /proc/net/xfrm_stat conta falhas agregadas como estado em falta, política em falta e erros de protocolo. Esses totais acumulam desde o arranque e pertencem a um único espaço de nomes de rede, pelo que um número grande não é uma atribuição.
Faça duas leituras em torno da janela do incidente no espaço de nomes correto e compare os deltas, caso contrário vai atribuir os erros da semana passada ao bilhete desta tarde. Coloque o espaço de nomes e ambos os carimbos temporais no bilhete para que o próximo leitor possa reproduzir a comparação em vez de confiar num total.
Nomeie a etapa, não o suspeito
Uma conclusão útil diz onde o pacote parou: nunca recebido, recebido e descartado, entregue mas sem resposta, ou respondido e perdido no caminho de volta. Cada um destes aponta para um responsável diferente e um comando seguinte diferente. „Sem resposta do servidor VPN“ colapsa quatro avarias distintas numa frase que a captura nunca justificou.
Mantenha as capturas estreitas e deixe o estado cru do kernel fora dos bilhetes, porque pode transportar material de chave que não deve sair do anfitrião. Os deltas dos contadores e os carimbos temporais são as partes que vale a pena entregar à pessoa seguinte.