IPsec ESP: o que ele transporta e como provar que está fluindo

O ESP transporta o tráfego numa VPN IPsec, e o seu runbook começa com uma regra: leia a associação de segurança antes de mudar uma política. A maior parte do comportamento inexplicado do ESP remonta a um seletor que não correspondia, a um modo que foi assumido em vez de lido, ou a um contador que ninguém verificou enquanto um único fluxo era enviado. Os três passos abaixo estabelecem o que transporta o quê, provam que um fluxo o usa e deixam uma reversão que não depende da memória. Cada passo produz uma observação que vale a pena anotar.

Conheça os campos antes de os ler

O ESP coloca um cabeçalho à frente dos dados protegidos e um trailer atrás. O cabeçalho carrega um índice de parâmetros de segurança que identifica qual associação o recetor deve usar, um número de sequência para detetar repetições e, no trailer, preenchimento que mantém a carga útil alinhada para a cifra. O campo de cabeçalho seguinte no trailer diz qual é o conteúdo protegido, e é assim que o recetor sabe o que desencapsulou.

O modo muda o que está dentro dessa proteção. No modo túnel o material protegido é um pacote IP interno completo, e um novo cabeçalho exterior transporta-o entre os extremos. No modo transporte a proteção envolve a carga útil da camada superior de um pacote existente, pelo que não há um segundo cabeçalho IP para abrir. Qual o modo em uso é um facto de configuração, não uma questão de interpretação. Leia-o na entrada de estado em vez de o inferir de um diagrama.

Nenhum dos modos esconde o endereçamento exterior que tem de entregar o pacote. Isso é uma propriedade do desenho e não uma falha, e é por isso que um observador intermédio ainda consegue ver que dois endereços estão a falar, mesmo quando a carga útil é opaca.

Passo um: leia o estado e depois a política

As entradas de estado guardam as chaves e os contadores; as entradas de política guardam os seletores que decidem o que os pode usar. No Linux ambos são visíveis sem capturar pacotes, e lê-los nessa ordem mantém as duas perguntas separadas.

ip xfrm state
ip xfrm policy

Na saída de estado, verifique a origem e o destino da associação, o modo e se o encapsulamento mostra portas UDP. Essas portas significam que a travessia de NAT está em uso, o que muda o que uma firewall intermédia tem de permitir, mas não quais seletores ou chaves se aplicam nos extremos.

Depois leia os seletores na política. Um seletor que indica um prefixo mais estreito do que o tráfego que está a testar é o motivo mais comum para um túnel que funciona parecer ignorar um fluxo, e um seletor para o protocolo errado produz o mesmo silêncio.

As ferramentas dos fabricantes imprimem a mesma informação de forma mais cómoda. ipsec statusall no strongSwan lista as associações filhas, os seus seletores e os seus contadores de bytes, o que é muitas vezes mais rápido do que ler a saída xfrm em bruto quando já sabe que filha observar.

Passo dois: prove que um fluxo move os contadores

Os contadores só fazem sentido se souber o que os deveria ter movido, por isso escolha uma origem e um destino que o seletor cubra com certeza e envie um pedido inofensivo. Depois releia a mesma entrada e compare.

ip -s xfrm state
tcpdump -ni any esp

Duas leituras contam histórias diferentes. Os pacotes que aumentam no lado de saída mas nunca no de entrada apontam para um problema de encaminhamento ou de caminho de retorno e não de chave, porque o pacote foi encapsulado e partiu. Se nenhum contador se mover, o tráfego nunca correspondeu à política, e o seletor é o local onde olhar.

A captura no mesmo passo confirma o encapsulamento no fio, incluindo se os pacotes exteriores são ESP ou ESP encapsulado em UDP. Também lhe mostra os endereços que realmente transportaram o fluxo, e esses às vezes diferem dos da configuração que estava a ler.

Passo três: mude uma coisa e mantenha uma reversão

Anote a origem, o destino, o modo, os seletores e os contadores da associação antes de editar o que quer que seja. Se uma alteração piorar as coisas, é essa nota que lhe permite restaurar o estado anterior em vez de reconstruir uma configuração funcional a partir de uma suposição. A nota leva um minuto a escrever e poupa uma hora mais tarde. É também o único artefacto que sobrevive à pessoa que fez a alteração.

Mude um seletor ou um parâmetro, recarregue-o e repita o passo dois sobre o mesmo fluxo. Apagar uma associação derruba todos os fluxos que a usam, por isso uma edição dirigida e um recarregamento da filha são quase sempre melhores do que esvaziar o estado para ver o que acontece.

A reversão de uma edição de seletor é restaurar a política anterior e recarregá-la, com a ressalva de que o par pode precisar de uma alteração correspondente se o seletor for negociado e não local. Anote essa dependência enquanto está fresca, porque um par meio restaurado é mais difícil de raciocinar do que qualquer um dos dois estados finais.

Por fim, mantenha o âmbito honesto. Uma associação ESP a fluir prova que as duas passarelas protegem e entregam o segmento, e não diz nada sobre se a aplicação por cima autentica os seus utilizadores ou cifra o que armazena. São controlos separados com provas separadas, e o runbook só termina quando a pessoa seguinte consegue repeti-lo a partir das notas.