Inspeccionar una interfaz VPN de Linux con ip link, capa por capa

El icono del cliente dice conectado, la interfaz existe y la aplicación sigue sin llegar a nada. Esa combinación es habitual, porque una interfaz virtual puede seguir presente mientras faltan su par remoto, sus direcciones o sus rutas. ip link es la primera herramienta correcta y también la más fácil de sobreinterpretar. Los indicadores y los contadores describen una capa, y las capas que están por encima fallan de forma independiente. Es además la herramienta que la gente cita cuando quiere demostrar que el túnel está levantado, justo la afirmación que no puede sostener por sí sola.

Lee la interfaz antes de leer el icono

Empieza con ip -details link show dev tun0 tal como se documenta en el manual de ip-link, sustituyendo el nombre convencional por la interfaz que tu cliente posee realmente. Los indicadores, el tipo, la MTU y la identidad de la interfaz son observaciones útiles. La redacción del estado de una interfaz virtual no tiene que comportarse como la indicación de portadora de un cable físico, así que trata UP como una afirmación sobre la interfaz y no sobre el túnel.

Esa distinción explica el caso más desconcertante: una interfaz que persiste mientras el lado remoto se reconecta o es inalcanzable.

Los ajustes de persistencia pueden mantener el enlace precisamente para que la reconexión no lo reconstruya, lo que significa que la presencia no es salud.

Añade contadores y una petición que debería usarlos

Usa la vista de estadísticas compatible ip -s link show dev tun0, y anota los contadores de paquetes y bytes en ambos sentidos. Después genera una petición inocua que debería atravesar la interfaz y compara el sentido relevante. Una petición que tomó la ruta directa de otra aplicación no moverá esos contadores, y ese es el sentido del ejercicio.

Si el contador de transmisión se mueve y el de recepción no, el paquete salió y no volvió nada. Es un problema distinto del de una interfaz que nunca transportó nada. Si ambos contadores se mueven y la aplicación sigue fallando, la avería está por encima de la interfaz, lo que es un avance y no un callejón sin salida.

Toma la lectura dos veces, una antes y otra después, en lugar de confiar en una sola instantánea.

Las direcciones y las rutas son pasos separados

Un enlace puede existir sin el prefijo, la configuración del resolutor o la ruta que necesita la aplicación. Comprueba la dirección con ip address show dev tun0, después comprueba qué ruta elegiría el destino con ip route get para el objetivo real. Esas tres observaciones responden a tres preguntas distintas, y solo la última trata del reenvío.

En IPsec también pueden importar la política de seguridad y el estado de la asociación, y no todos los diseños IPsec aparecen como una interfaz tun simple. Buscar un dispositivo tun que nunca iba a existir es una vía rápida a una conclusión equivocada.

Anota el nombre exacto, el espacio de nombres y la hora junto a cualquier salida que conserves, porque un nombre de aspecto idéntico en otro contenedor o en una sesión restaurada representa un contexto completamente distinto.

No borres lo que no has identificado

Una interfaz desconocida no está obsoleta automáticamente. Identifica a su propietario antes de quitar nada y, cuando la retirada sea realmente intencionada, usa el desmontaje documentado del cliente o la configuración gestionada. Borrar un túnel activo para ver qué pasa es una prueba que responde a una pregunta que nadie hizo.

Si la interfaz pertenece a un entorno de contenedores o a un espacio de nombres de red que no creaste, el propietario está a una orden de distancia y merece la pena encontrarlo primero.

Esa precaución se aplica también a ip link set down, que parece reversible y a menudo no lo es.

Qué debería dejarte la inspección

Una buena inspección termina con cuatro hechos: el nombre y el espacio de nombres de la interfaz, sus indicadores y la MTU, el delta de contadores de una petición real, y la ruta y la dirección que la aplicación necesita de verdad. Con eso escrito, el paso siguiente es obvio y pertenece a una capa concreta. Sin eso, cada cambio posterior es una suposición con un plan de reversión.

Compara esos cuatro hechos con los mismos cuatro de una sesión que funciona. Si el nombre y el espacio de nombres coinciden pero el delta de contadores es cero, la petición nunca llegó al túnel. Si el delta es saludable y la ruta apunta a otro sitio, el túnel está bien y el enrutamiento no. Esa comparación es lo que convierte un montón de salida en una decisión.

Guarda la salida con el ticket, porque una comparación posterior solo sirve si ves qué cambió.

Después cierra el círculo probando la aplicación otra vez, porque la interfaz nunca fue lo que le importaba al usuario.