Enrutamiento recursivo: cuando el túnel captura sus propios paquetes

El túnel se levanta, el registro muestra un protocolo de enlace completado y, un segundo después, la misma sesión muere y se reconecta en bucle. Ese patrón tiene una causa concreta: la ruta al servidor ahora apunta hacia dentro del túnel, así que los paquetes que transportan el túnel se envían por el túnel. Nada ha cambiado en la autenticación, y por eso volver a introducir las credenciales no sirve de nada. Compare el camino exterior antes y después del cambio de la ruta y la recursión se hace visible.

Compruebe primero el camino exterior

Hay dos paquetes en juego, no uno. El paquete interior pertenece a la aplicación y debería ir cifrado, mientras que el paquete exterior va dirigido al servidor y debe llegar a él por un camino que no dependa del túnel.

ip route get 198.51.100.7
ip rule show
ip route show table all | grep -F 198.51.100.7
wg show wg0 endpoints

Pregunte al núcleo por la ruta a la dirección del servidor una vez levantado el túnel, y otra vez después de que cambie la ruta predeterminada. Un siguiente salto que aterrice en el dispositivo del túnel es la recursión, y se ve sin ninguna captura de paquetes. El enlace a una interfaz, las marcas o un espacio de nombres de red pueden dejar incompleta una consulta simple, así que use el contexto que usa el propio cliente. Cuando la respuesta parece correcta pero la sesión sigue en bucle, lea las reglas de la política de enrutamiento y no solo la tabla principal.

Por qué la sesión sobrevive un momento

El protocolo de enlace se completa antes de que se instale la ruta nueva, así que los primeros segundos parecen sanos. En cuanto el cliente añade la ruta predeterminada, el siguiente paquete exterior la sigue hacia la interfaz por la que ese paquete exterior tiene que viajar. El servidor no ve nada, el cliente retransmite y el intento o bien expira o bien mata la sesión y empieza de nuevo.

Ese orden explica por qué un túnel puede funcionar en un portátil y fallar en un router, y por qué el fallo suele empezar cuando arranca el tráfico y no al conectar. También explica el bucle: cada reinicio restablece la sesión antes de que la ruta lo haga imposible.

Averigüe quién es dueño de la excepción del extremo

Los clientes compatibles preparan su propia excepción: una ruta de host al servidor a través de la pasarela original, o una marca que mantiene el zócalo exterior fuera del túnel. La pregunta es si algo más la ha eliminado o la ha anulado.

En IPsec basado en rutas, revise los selectores de política que deciden qué paquetes entran en el túnel y confirme que la dirección del par queda excluida de ellos. En WireGuard, la marca de cortafuegos de la interfaz y sus reglas de política mantienen los paquetes de transporte fuera del túnel, así que una ruta predeterminada añadida a mano puede romper esa disposición. Un segundo perfil de VPN o un script de administración que reescriba la ruta predeterminada es un culpable habitual. Las reglas de omisión amplias añadidas una a una son el resultado normal, y convierten un error de enrutamiento en una tabla que nadie puede mantener.

Vuelva a comprobar tras un cambio de red

Una ruta de host por una pasarela Wi-Fi es correcta hasta que la máquina pasa a otra red. Entonces el mismo síntoma vuelve sin ningún cambio de configuración.

Anote la dirección del extremo, la ruta antes y después de conectar y la interfaz que usó cada una. Esos tres hechos suelen separar un error del cliente de una anulación, y sobreviven a la persona que los recogió.

Vuelva a conectar en la red nueva y repita la lectura. Si la excepción vuelve a faltar, la corrección corresponde al perfil que la posee, no a un comando puntual escrito durante una avería.