El túnel sigue activo, la ruta desapareció: separar dos fallos de VPN

Un host deja de ser accesible mientras la interfaz del túnel sigue informando que está establecida, y las dos observaciones no se contradicen. Algo eliminó el camino que usaba el tráfico: un vecino retiró su prefijo, se retiró una ruta estática seguida o otra ruta pasó a ser preferida. La asociación de seguridad puede permanecer perfectamente sana en los tres casos. Separar los sucesos significa preguntar qué capa cambió primero, no si la VPN falló.

Tres etapas que parecen un solo suceso

Una decisión de enrutamiento tiene tres etapas. El prefijo se recibe, se selecciona como el mejor y se instala en la tabla de reenvío. Cada etapa puede fallar por sí sola, y el fallo se ve idéntico desde el lado de la aplicación. Un prefijo que se aprendió pero perdió la selección es indistinguible de uno que nunca llegó cuando la única prueba que se mira es la tabla de reenvío.

Por eso la primera pregunta es qué etapa se rompió, no qué protocolo tiene la culpa. La respuesta decide quién es dueño del incidente y qué herramienta usa la siguiente comprobación.

Lea primero la ruta instalada

Pregunte al kernel adónde va realmente el tráfico hacia el destino que falla. ip route get imprime el siguiente salto, la interfaz y la dirección de origen que usaría el kernel, y responde para un destino en lugar de para toda la tabla. Si la respuesta nombra el túnel, la tabla de reenvío sigue creyendo que el camino existe y el problema está por encima.

ip route get 10.20.5.10
ip route show 10.20.0.0/16

Una respuesta «unreachable» significa que no hay ninguna ruta instalada, lo que apunta a una retirada o a una instalación que falta. Una respuesta que nombra una interfaz física significa que el tráfico salió del túnel sin que nadie lo decidiera, y la siguiente comprobación es la preferencia que ganó. Una respuesta que nombra el túnel mientras los paquetes siguen desapareciendo apunta más abajo en el camino, al filtrado o al lado remoto.

Después mire la visión del propio protocolo

Un demonio de enrutamiento mantiene más de una tabla, y la comparación interesante es entre ellas. En BGP, el estado de la sesión vecina, el anuncio recibido y la ruta instalada son tres pruebas separadas. Un prefijo puede quedarse en la tabla recibida y no llegar nunca al kernel porque gana una ruta con una distancia administrativa más corta. Compruebe las tres antes de concluir que el otro lado dejó de anunciar.

vtysh -c "show bgp summary"
vtysh -c "show bgp ipv4 unicast 10.20.0.0/16"

El resumen le dice si la sesión está establecida, la vista por prefijo le dice si el prefijo se aceptó, y la consulta al kernel le dice si se instaló. Leerlas en ese orden evita que un parpadeo de sesión se confunda con una retirada, y una retirada con un rechazo por política.

Cuando los relojes no coinciden

Ponga el registro del túnel, el registro de enrutamiento y el primer fallo de la aplicación en una sola línea de tiempo usando sus zonas horarias reales. Si la pérdida del vecino llega primero, el túnel derribó la ruta con él. Si la retirada llega primero, el enrutamiento cambió y el túnel reaccionó después. Son incidentes distintos con dueños distintos, y el orden es todo el hallazgo.

Un minuto de desviación del reloj basta para invertir esa conclusión, así que confirme la zona horaria y el desplazamiento antes de fiarse de la secuencia. Los dispositivos que registran en hora local sin desplazamiento son la fuente habitual de una línea de tiempo segura pero equivocada.

Recuperación sin bucle

Tras una retirada pueden ser elegibles dos caminos: el que selecciona el protocolo y el que se fija a mano. Solo el primero es una decisión que la red sigue tomando por usted, por eso una ruta manual es un apaño y no un plan de recuperación. Un anuncio alternativo tampoco conserva el estado del cortafuegos ni del NAT para una sesión ya establecida, así que los flujos nuevos pueden funcionar mientras el original sigue roto. Confirme qué respaldo debe activarse y si el sitio remoto aceptará un camino de retorno a través de él.

No instale una anulación estática permanente antes de entender por qué se produjo la retirada. Ese atajo puede fijar el tráfico a un camino fallido o saltarse en silencio una política de enrutamiento deliberada, y entierra la causa original bajo una configuración nueva. Vuelva a probar la aplicación cuando la ruta esté restaurada y confirme que el prefijo elegido tiene un camino de datos funcional y no solo una entrada en una tabla.