Por qué una ruta VPN no muestra ninguna puerta de enlace en la salida de ip route

Las tablas de enrutamiento se leen como rotas cada vez que la columna de la puerta de enlace queda vacía, cuando la línea suele estar completa por sí sola. El campo via aparece solo cuando el núcleo entrega el paquete a una dirección de siguiente salto; una ruta ligada a una interfaz alcanza sus destinos mediante resolución de capa de enlace o mediante un par punto a punto. Leer las columnas de izquierda a derecha te dice en qué caso estás, y esa lectura debería ocurrir antes de que alguien edite una ruta predeterminada. La mayoría de los tiques sobre una puerta de enlace ausente terminan en esta distinción.

Lee una línea de ruta columna por columna

Cada entrada comienza con el destino y la longitud de su prefijo, y luego añade modificadores en un vocabulario fijo: via, dev, proto, scope, src y metric. Una línea como 198.51.100.0/24 dev tun0 proto kernel scope link src 198.51.100.2 es densa pero está completamente especificada. No le falta nada y no se implica ninguna dirección de router.

La ausencia de via es la parte interesante. Sin un siguiente salto, el núcleo resuelve el destino directamente en la interfaz indicada, lo que para un túnel significa entregar la trama al dispositivo de túnel y dejar que la encapsulación se encargue a partir de ahí. proto kernel registra que la entrada se instaló automáticamente cuando se asignó una dirección, no que la escribiera un administrador. scope link dice que el destino es alcanzable en ese enlace sin pasar por un router, y src nombra la dirección que el núcleo preferirá como origen para el tráfico que coincida.

Ahora lee una ruta predeterminada de la misma manera: default via 192.0.2.254 dev eth0 proto static metric 100. Aquí via está presente porque el paquete sí necesita un siguiente salto, y ese salto debe ser alcanzable a su vez en eth0. Las dos líneas no son variantes una de otra; responden a preguntas distintas sobre adónde va el tráfico.

Dos formas de ruta que se confunden entre sí

Una ruta de subred de túnel y una ruta predeterminada se parecen en una captura de pantalla y se comportan de forma totalmente distinta. Usa la tabla de abajo como ayuda de lectura para los campos y luego confirma los números reales en la máquina que estás depurando en lugar de fiarte de una muestra de una guía.

Lo que la tabla no puede decirte es la intención. Una ruta directa a un rango privado a través de un túnel es un diseño deliberado de túnel dividido; la misma forma en un host que debería enviarlo todo por la VPN es un síntoma. La intención vive en la configuración que produjo la entrada, así que mira la herramienta que la instaló antes de concluir que el núcleo se equivocó.

Del mismo modo, que falte una puerta de enlace no es permiso para inventar una. Si una ruta necesita de verdad un siguiente salto, ese salto tiene que ser alcanzable en la interfaz que lo transporta, y para un túnel punto a punto la dirección del par no es el mismo objeto que la dirección local. Tratar la dirección local del túnel como un router Ethernet es una forma habitual de producir una ruta que parece correcta y no reenvía nada.

Pregunta al núcleo qué línea va a usar realmente

Leer la tabla no es lo mismo que realizar la consulta, porque el núcleo consulta reglas de política, varias tablas y entradas en caché antes de responder. El verbo que realiza la consulta real es ip route get, y muestra la ruta que tomaría un paquete con esas propiedades.

ip route get 203.0.113.37 from 198.51.100.2 iif tun0

Sustituye el destino que de verdad te importa y luego añade from o iif cuando el tráfico se selecciona por origen o se reenvía, porque una consulta local ordinaria puede elegir un camino distinto del que elige un cliente reenviado. La respuesta nombra la interfaz, la dirección de origen elegida y cualquier siguiente salto, que es la misma información con la que se enrutaría un paquete en ese momento.

Si la respuesta te sorprende, imprime las reglas antes de cambiar nada: ip -4 rule show las enumera por orden de prioridad, y un cliente VPN que instale su propia tabla o una regla para paquetes marcados no aparecerá en absoluto en la tabla principal. Enumerar todas las tablas cierra ese hueco.

ip -4 route show table all | grep -E 'tun|default'

Comprueba la capa subyacente antes de sustituir la ruta predeterminada

Los paquetes propios del túnel tienen que llegar al extremo remoto, y lo hacen por la interfaz física usando la ruta que existía antes de que se levantara la VPN. Sustituir toda la ruta predeterminada sin fijar ese extremo envía los paquetes encapsulados al túnel que se supone que deben construir, y la conexión se derrumba. Confirma primero el camino al extremo con una consulta solo de su dirección.

Mantén tres cosas separadas cuando hagas el cambio: la ruta al extremo que debe quedarse en la interfaz física, los rangos privados que deberían entrar en el túnel y la ruta predeterminada que decide todo lo demás. Sepáralas en ese orden, aplica una a la vez y vuelve a ejecutar la consulta después de cada paso. Un ping fallido después demuestra muy poco por sí solo, ya que los permisos, el enrutamiento de respuestas, el DNS y el servicio mismo quedan todos aguas abajo de una ruta correcta.

Anota los cuatro valores que te dio la línea antes de la edición: destino, siguiente salto o su ausencia, dispositivo y origen elegido. Si un cambio posterior mueve cualquiera de ellos, sabes qué decisión se alteró en realidad, y puedes restaurar una entrada en lugar de adivinar toda la tabla.