La respuesta sale por la LAN, no por el túnel: por qué y cómo

Un servicio publicado a través de una puerta de enlace funciona desde la mayor parte de internet y falla desde una oficina. Alguien revisa el túnel, ve llegar la solicitud y concluye que la respuesta debe seguir el mismo camino de vuelta. Linux no funciona así, y ninguna inspección del túnel cambiará la respuesta. La respuesta se enruta por destino, y ese único solicitante que falla está en una subred a la que el equipo ya llega directamente.

Qué decide realmente un paquete saliente

El núcleo busca una ruta para el destino del paquete, consultando las reglas de política por orden de prioridad y después la tabla que selecciona una regla coincidente. La interfaz por la que llegó un paquete no influye, salvo que se haya escrito una regla o una marca para que importe. Es un hecho de enrutamiento de este equipo, no un fallo del túnel.

Por tanto, una solicitud recibida por el túnel puede producir una respuesta que sale por la interfaz física, y el flujo se vuelve unidireccional sin que ningún dispositivo informe de un error. Comprueba ambas direcciones antes de sacar una conclusión sobre el túnel. Una respuesta que sale por el lado equivocado desaparece de los contadores del túnel, y por eso los dos extremos no coinciden sobre si se envió algo. Fíjate en qué contador se movió antes de tocar una regla.

Por qué gana la subred local

Un equipo con una dirección en una red local tiene una ruta conectada para ese prefijo en la tabla principal, y una ruta conectada es una coincidencia directa. Cuando el solicitante viene de esa misma subred, la búsqueda encuentra el enlace local antes de que el túnel se considere siquiera.

La asimetría es lo que hace que el diagnóstico sea confuso. Los solicitantes del resto de internet funcionan porque no coinciden con ninguna ruta local, mientras que el único solicitante que comparte el prefijo de la oficina falla, que es justo el solicitante con el que alguien prueba.

La cobertura de pares no es lo mismo que las rutas instaladas

En el lado del túnel, los rangos permitidos de un par describen qué puede enviarse al túnel y qué fuentes se aceptan de él. No dicen nada sobre adónde enviará un paquete la tabla de enrutamiento local.

Si la herramienta del túnel instala una ruta predeterminada en el equipo, puede arrastrar tráfico no relacionado al túnel como daño colateral. Donde una regla de política debería ser la dueña de la decisión, la opción de instalación de rutas de la herramienta existe precisamente para impedirlo, y las direcciones, las claves y la configuración del extremo quedan exactamente como estaban. Una ruta predeterminada añadida por comodidad es una forma habitual de que un equipo pierda su propia red local.

Selecciona la tabla por la dirección de origen

Una regla basada en el origen envía las respuestas desde la dirección del servicio a una tabla privada cuyo valor predeterminado es el túnel, mientras que todo lo demás sigue usando la tabla principal. Elige números de tabla y de prioridad que no se usen localmente, y lee las reglas existentes antes de insertar nada. Lee las reglas activas en lugar de un archivo guardado, porque ambos pueden diferir tras un reinicio.

ip -6 route add default dev wg0 table 200
ip -6 rule add priority 32000 from 2001:db8:aa::20/128 lookup 200
ip -6 rule add priority 32001 from 2001:db8:aa::20/128 unreachable

La última línea hace que una ruta ausente falle de forma visible en lugar de recaer en el enlace local. El origen debe estar realmente asignado al equipo, y las búsquedas locales y principales ordinarias deben permanecer en sus posiciones anteriores. La regla elige una tabla por origen; no compara longitudes de prefijo entre tablas.

Confirma la ruta y después el servicio

Pregunta al núcleo qué haría en lugar de inferirlo de una captura, usando la dirección del servicio como selector de origen. Una respuesta equivocada aquí ahorra todo un rastreo de paquetes.

ip -6 route get 2001:db8:bb::30 from 2001:db8:aa::20

La salida debería nombrar el túnel. Luego prueba un origen que no hayas tocado y confirma que sigue tomando el enlace local, de modo que el cambio quedó limitado a una dirección. Un selector más amplio no demostraría nada sobre la queja original.

Qué no arregla esto

Deja el reenvío, las reglas del cortafuegos y el comportamiento de ICMPv6 en la puerta de enlace como estaban, porque una ruta de origen no sustituye ninguna de ellas. Un mensaje Packet Too Big ausente sigue rompiendo las respuestas grandes, gane la búsqueda la tabla que gane. Corrige eso antes de añadir reglas de enrutamiento, o el síntoma sobrevivirá al cambio.

Confirma el modelo de publicación antes de aplicar nada de esto. Un proxy inverso que abre su propia conexión de backend presenta su propio origen y no conserva al solicitante, así que este fallo no puede ocurrir en ese diseño. Aplicar la regla allí añadiría una excepción de enrutamiento que no resuelve nada y oculta la causa real.

Por último, escribe los números de regla y la tabla en la gestión de configuración del equipo. Una regla de política añadida a mano desaparece en la siguiente reconstrucción, y el solicitante de la oficina vuelve con la misma queja.