Monitorar uma interface de túnel IPsec: o que ler

Um projeto IPsec baseado em rotas instala uma interface virtual, e essa interface dá ao monitoramento um objeto concreto: algo com um nome, contadores e uma rota associada a ele. Não é, por si só, um sinal de saúde. A interface pode existir enquanto nenhuma associação utilizável está instalada, e uma associação pode estar saudável enquanto nenhuma rota envia a ela o tráfego de interesse. É ler quatro estados em conjunto que transforma uma contagem de pacotes em um diagnóstico.

Percorra-os na ordem e pare no primeiro que falhar.

O que a interface acrescenta ao quadro

Com um projeto baseado em políticas, a seleção fica na tabela de políticas IPsec e o kernel decide o que é protegido a partir dos seletores de tráfego. Um projeto baseado em rotas acrescenta uma interface e uma rota, de modo que o tcpdump e os contadores da interface veem uma única fronteira em vez de um conjunto de seletores. É um ganho real para o diagnóstico e para os protocolos de roteamento que precisam de uma interface para estabelecer peering.

O ganho é administrativo, não criptográfico. A interface relata o tráfego que transporta e não diz nada sobre se a proteção do par está utilizável no momento.

Ler os quatro estados antes de culpar o túnel

Comece pela interface e pela rota, depois pela associação e depois pela aplicação. Cada uma tem seu próprio comando e sua própria assinatura de falha. Um resultado limpo em uma camada não é um resultado limpo na seguinte. Execute as quatro antes de tirar uma conclusão. Uma linha verde raramente resolve alguma coisa.

ip -s link show xfrm0
ip route get 10.20.30.40
ip xfrm state
ip xfrm policy
swanctl --list-sas
tcpdump -ni xfrm0 -c 20 host 10.20.30.40

Uma interface com contador subindo mas sem entrada de estado correspondente descreve tráfego entrando em um caminho onde nada o protege, o que é pior do que um túnel simplesmente fora do ar. Uma entrada de estado sem rota que selecione a interface significa que a criptografia está pronta e sem uso.

O teste da aplicação vem por último e de propósito: um ping bem-sucedido para o outro lado do túnel não prova que o serviço por trás dele aceite conexões.

Comparar os contadores internos com os externos

Os contadores na interface de túnel medem o tráfego interno; contadores e capturas na interface física mostram a troca encapsulada. Os dois não vão coincidir um a um, porque a encapsulação acrescenta cabeçalhos, as retransmissões duplicam alguns pacotes e a contabilidade da implementação segue regras próprias. Espere uma proporção, não uma igualdade.

A posição da captura também decide que dados privados são coletados, por isso use filtros estreitos e um endereço de teste inofensivo em vez de uma captura completa do tráfego de produção.

Se as contagens internas sobem e as externas não, a etapa que falta costuma ser a rota ou a política que envia os pacotes para o túnel, e não o túnel em si.

Observar durante a renegociação de chaves e o failover

Observe uma renegociação de chaves, um evento de detecção de par morto e um failover de enlace enquanto acompanha os mesmos quatro estados. Uma interface pode permanecer presente durante uma renegociação que nunca se completa, e um failover pode deixar uma entrada de estado apontando para um endereço de par que não é mais alcançável.

Alerte sobre o caminho de serviço de que realmente depende, com o estado da associação como contexto, em vez de sobre um único indicador de ativo ou inativo. Mantenha o nome da interface, o endereço do par e a rota na carga do alerta, para que quem responde não precise reconstruí-los.

O strongSwan documenta seu próprio modelo de interface XFRM, e outras plataformas nomeiam e implementam o objeto equivalente de forma diferente. Leia a comparação baseada em rotas do dispositivo à sua frente antes de transferir suposições de outra implementação. Um modelo de monitoramento adequado aos contadores de um fornecedor enganará em silêncio em outro.