Supervisar una interfaz de túnel IPsec: qué leer

Un diseño IPsec basado en rutas instala una interfaz virtual, y esa interfaz entrega a la supervisión un objeto concreto: algo con un nombre, contadores y una ruta asociada. No es una señal de salud por sí mismo. La interfaz puede existir mientras no hay instalada ninguna asociación utilizable, y una asociación puede estar sana mientras ninguna ruta le envía el tráfico interesante. Leer cuatro estados en conjunto es lo que convierte un recuento de paquetes en un diagnóstico.

Recórrelos en orden y detente en el primero que falle.

Qué aporta la interfaz al panorama

Con un diseño basado en políticas, la selección vive en la tabla de políticas IPsec y el kernel decide qué queda protegido a partir de los selectores de tráfico. Un diseño basado en rutas añade una interfaz y una ruta, de modo que tcpdump y los contadores de la interfaz ven una sola frontera en lugar de un conjunto de selectores. Es una ganancia real para el diagnóstico y para los protocolos de enrutamiento que necesitan una interfaz sobre la que establecer peering.

La ganancia es administrativa, no criptográfica. La interfaz informa del tráfico que transporta y no dice nada sobre si la protección del par es utilizable en este momento.

Leer los cuatro estados antes de culpar al túnel

Empieza por la interfaz y la ruta, luego por la asociación y luego por la aplicación. Cada una tiene su propio comando y su propia firma de fallo. Un resultado limpio en una capa no es un resultado limpio en la siguiente. Ejecuta las cuatro antes de sacar una conclusión. Una línea verde rara vez resuelve 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

Una interfaz con un contador que sube pero sin entrada de estado correspondiente describe tráfico que entra en un camino donde nada lo protege, lo cual es peor que un túnel simplemente caído. Una entrada de estado sin una ruta que seleccione la interfaz significa que la criptografía está lista y sin usar.

La prueba de la aplicación llega al final y a propósito: un ping exitoso al extremo opuesto del túnel no demuestra que el servicio que hay detrás acepte conexiones.

Comparar los contadores internos con los externos

Los contadores de la interfaz de túnel miden el tráfico interno; los contadores y las capturas de la interfaz física muestran el intercambio encapsulado. Los dos no coincidirán uno a uno, porque la encapsulación añade cabeceras, las retransmisiones duplican algunos paquetes y la contabilidad de la implementación sigue sus propias reglas. Espera una proporción, no una igualdad.

La ubicación de la captura también decide qué datos privados recoges, así que usa filtros estrechos y una dirección de prueba inofensiva en lugar de una captura completa del tráfico de producción.

Si los recuentos internos suben y los externos no, el paso que falta suele ser la ruta o la política que envía los paquetes al túnel, no el túnel en sí.

Observarlo durante la renegociación y el failover

Observa una renegociación de claves, un evento de detección de par muerto y un failover de enlace mientras vigilas los mismos cuatro estados. Una interfaz puede seguir presente durante una renegociación que nunca termina, y un failover puede dejar una entrada de estado apuntando a una dirección del par que ya no es alcanzable.

Alertar sobre la ruta de servicio de la que realmente dependes, con el estado de la asociación como contexto, en lugar de sobre un simple indicador de arriba o abajo. Conserva el nombre de la interfaz, la dirección del par y la ruta en la carga útil de la alerta, para que quien responda no tenga que reconstruirlos.

strongSwan documenta su propio modelo de interfaz XFRM, y otras plataformas nombran e implementan de forma distinta el objeto equivalente. Lee la comparación basada en rutas del dispositivo que tienes delante antes de trasladar supuestos de otra implementación. Una plantilla de supervisión que encaja con los contadores de un fabricante engañará en silencio con otro.