Supervisión dunha interface de túnel IPsec: que ler

Un deseño IPsec baseado en rutas instala unha interface virtual, e esa interface dálle á supervisión un obxecto concreto: algo cun nome, contadores e unha ruta asociada. Non é un sinal de saúde por si mesmo. A interface pode existir mentres non hai instalada ningunha asociación utilizábel, e unha asociación pode estar sá mentres ningunha ruta lle envía o tráfico interesante. Ler catro estados en conxunto é o que converte un reconto de paquetes nun diagnóstico.

Percórreos por orde e detente no primeiro que falle.

Que achega a interface ao panorama

Nun deseño baseado en políticas, a selección vive na táboa de políticas IPsec e o kernel decide que queda protexido a partir dos selectores de tráfico. Un deseño baseado en rutas engade unha interface e unha ruta, de xeito que tcpdump e os contadores da interface ven unha soa fronteira en lugar dun conxunto de selectores. É unha ganancia real para o diagnóstico e para os protocolos de encamiñamento que precisan unha interface sobre a que estabelecer peering.

A ganancia é administrativa, non criptográfica. A interface informa do tráfico que transporta e non di nada sobre se a protección da parella é utilizábel neste momento.

Le os catro estados antes de culpar o túnel

Comeza pola interface e a ruta, despois pola asociación e despois pola aplicación. Cada unha ten o seu propio comando e a súa propia sinatura de fallo. Un resultado limpo nunha capa non é un resultado limpo na seguinte. Executa as catro antes de sacar unha conclusión. Unha liña verde raramente resolve nada.

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

Unha interface cun contador que sobe pero sen entrada de estado correspondente describe tráfico que entra nun camiño onde nada o protexe, o que é peor que un túnel simplemente caído. Unha entrada de estado sen unha ruta que seleccione a interface significa que a criptografía está lista e sen usar.

A proba da aplicación chega ao final e a propósito: un ping exitoso ao outro lado do túnel non demostra que o servizo que hai detrás acepte conexións.

Compara os contadores internos cos externos

Os contadores da interface de túnel miden o tráfico interno; os contadores e as capturas da interface física amosan o intercambio encapsulado. Os dous non coincidirán un a un, porque a encapsulación engade cabeceiras, as retransmisións duplican algúns paquetes e a contabilidade da implementación segue regras propias. Espera unha proporción, non unha igualdade.

A localización da captura tamén decide que datos privados recolles, así que usa filtros estreitos e un enderezo de proba inofensivo en lugar dunha captura completa do tráfico de produción.

Se os recontos internos soben e os externos non, o paso que falta adoita ser a ruta ou a política que envía os paquetes ao túnel, non o túnel en si.

Observa isto durante a renovación de chaves e o failover

Observa unha renovación de chaves, un evento de detección de parella morta e un failover de ligazón mentres vixías os mesmos catro estados. Unha interface pode seguir presente durante unha renovación de chaves que nunca remata, e un failover pode deixar unha entrada de estado apuntando a un enderezo de parella que xa non é alcanzábel.

Alerta sobre a ruta de servizo da que realmente dependes, co estado da asociación como contexto, en lugar de sobre un único indicador arriba ou abaixo. Conserva o nome da interface, o enderezo da parella e a ruta na carga útil da alerta, para que quen responde non teña que reconstruílos.

strongSwan documenta o seu propio modelo de interface XFRM, e outras plataformas nomean e implementan doutro xeito o obxecto equivalente. Le a comparación baseada en rutas para o dispositivo que tes diante antes de trasladar supostos doutra implementación. Un modelo de supervisión que encaixa cos contadores dun fabricante enganará en silencio con outro.