Por qué una ruta de túnel completo corta el servidor que la transporta

Activa un túnel completo y cada destino pasa a pertenecer a la interfaz VPN, incluida la máquina que lo termina. Los paquetes exteriores que transportan el túnel van dirigidos a esa máquina, así que la ruta acaba consumiendo el transporte del que depende. Una ruta específica adicional lo resuelve, y merece la pena entender el motivo. Sin ese motivo, la próxima reconstrucción vuelve a introducir el fallo.

Una ruta que se come su propio transporte

La encapsulación envuelve cada paquete en una segunda cabecera. La exterior va dirigida desde la dirección física local hasta la dirección pública del servidor, y tiene que cruzar el enlace físico antes de que pueda existir ningún túnel.

Ahora deja que la búsqueda de esa dirección pública elija el túnel. Para enviar el paquete, la máquina debe encapsularlo, lo que requiere una ruta hacia la misma dirección, que devuelve el túnel. Los clientes lo manejan de una de dos maneras. Uno cuidadoso se niega a instalar la ruta predeterminada e informa de un error, mientras que uno menos cuidadoso informa de éxito y luego no mueve nada. El fallo silencioso es el que cuesta una tarde.

La coincidencia de prefijo más largo decide la búsqueda antes de consultar ninguna métrica, así que una ruta de una sola dirección supera a cualquier ruta predeterminada de la máquina. Ese es todo el mecanismo detrás de la reparación.

Instala la excepción antes que la predeterminada

Crea una ruta de una sola dirección para el servidor, con la puerta de enlace física como siguiente salto, antes de que se mueva la ruta predeterminada. El orden importa: instalarla después significa convivir con un túnel roto mientras escribes.

La mayoría de los clientes lo hacen sin que se lo pidan. OpenVPN busca la dirección remota y la fija antes de reescribir la puerta de enlace predeterminada, y su opción route-delay existe para plataformas donde esa secuencia compite. wg-quick toma un camino totalmente distinto, marcando paquetes y consultando una regla de política en lugar de añadir una excepción. Mecanismos distintos, mismo requisito: el paquete exterior tiene que escapar del túnel que crea.

ip route add 203.0.113.10/32 via 192.168.1.1 dev eth0
ip route get 203.0.113.10

La salida de la búsqueda es la prueba de aceptación. Debe nombrar el dispositivo físico y el siguiente salto físico. Un dispositivo de túnel en esa respuesta significa que falta la excepción o que se colocó después de algo que la anula.

La imagen especular en el servidor

La misma trampa espera al otro lado, invertida. Da al servidor una ruta predeterminada por otro túnel, o empújale una ruta que cubra las direcciones públicas de los clientes, y sus respuestas adquirirán la costumbre de ir en dirección equivocada.

Imagina un cliente que se conecta y envía una petición. La respuesta va dirigida a la dirección pública de ese cliente, que ahora coincide con una ruta de túnel, así que sale por una interfaz distinta llevando un origen que el cliente nunca marcó. El cliente puede recibir ese paquete y aun así descartarlo, porque nada lo ata a la petición que envió. Parte de la decisión de enrutamiento del servidor en lugar del tiempo de espera del cliente, ya que solo una de las dos muestra la elección real.

ip route get 198.51.100.44 from 10.90.0.1
ip rule show
sudo tcpdump -ni any host 198.51.100.44

Existen tres reparaciones y no son iguales. Fijar el servicio a la dirección física, o traducir el origen, ambas esconden la decisión de enrutamiento en lugar de corregirla. Enviar el tráfico de respuesta del conjunto del túnel por una tabla dedicada corrige la causa, y las otras dos solo son aceptables mientras el diseño de enrutamiento esté congelado.

Excepciones que el túnel sigue robando

Un puñado de tareas necesitan el internet abierto incluso mientras el túnel posee la ruta predeterminada, y cada una necesita su propia excepción. El actualizador de DNS dinámico suele ser el primero en romperse.

Resuelve el proveedor, abre una conexión y descubre que sus propios paquetes viajan por un túnel cuya dirección cambió hace segundos, así que la actualización falla o publica la dirección equivocada. Tres salidas: fijar el proveedor con una ruta de host por la puerta de enlace física, ejecutar la actualización antes de que suba el túnel, o dar al actualizador una tabla de política que el túnel nunca toca. La sincronización horaria tiene la misma exposición en un dispositivo que arranca sin resolutor, y los extremos de validación de certificados pertenecen a la lista por el mismo motivo.

Una excepción que nadie escribió es una excepción que la próxima reconstrucción dejará caer en silencio.

Demuéstralo después de una reconexión, no antes

Prueba tres destinos, no uno: el extremo, una dirección privada detrás del túnel y una dirección pública más allá. Una sola búsqueda correcta no dice casi nada sobre las otras dos.

ip route get 203.0.113.10
traceroute -n 203.0.113.10
ip route get 10.90.0.5
ip route get 1.1.1.1

Luego reinicia la conexión, porque un cliente que reconstruye su tabla al reconectar descartará una ruta que escribiste a mano. Con un kill switch activo, comprueba que el extremo esté permitido, o el túnel no podrá volver tras un cambio de red y el síntoma parecerá una caída. Guarda la excepción en el perfil o en el archivo de unidad en lugar de en el historial del shell, para que la reconexión la vuelva a crear en vez de borrarla.