Tabla de enrutamiento frente a la consulta real: adónde va el tráfico VPN

Un volcado de la tabla de enrutamiento es el diagnóstico menos útil en la resolución de problemas de VPN y el que más se pega. Cuarenta líneas de prefijos le dicen qué podría hacer la máquina, no qué hizo para la solicitud que falló. El mecanismo que realmente quiere es la consulta: dados este origen y este destino, qué regla coincidió, qué tabla se consultó y qué interfaz y siguiente salto salieron. Empiece por un destino y un origen, lea después la tabla con esa pregunta en la mano, y la misma salida se convierte en evidencia en lugar de ruido.

Una tabla es un conjunto de candidatos, no una decisión

Cada entrada describe un prefijo y qué hacer con el tráfico que coincide con él: enviarlo a una interfaz, entregarlo a un siguiente salto o descartarlo. Nada en esa lista está ordenado por intención, y la entrada que a una persona le parece más específica no siempre es la que selecciona el kernel, porque la selección sigue la coincidencia de prefijo más larga y, entre prefijos iguales, la métrica.

Así que el primer paso es preguntar al kernel en lugar de leer la lista. El comando de consulta responde para un destino, y con un argumento de origen responde para el par exacto que usaría una conexión reenviada o vinculada:

ip route get 198.51.100.10
ip route get 198.51.100.10 from 10.80.0.25
ip -6 route get 2001:db8:10::40

Cada dirección anterior es un ejemplo de documentación. El punto es la forma de la respuesta: interfaz, dirección de origen elegida, puerta de enlace y la tabla de la que vino la entrada. Si esa salida no coincide con la interfaz que esperaba, ha localizado el problema con un solo comando, y ninguna cantidad de lectura de la tabla completa le habría dicho qué candidato ganó.

La consulta recorre primero reglas y luego tablas

En Linux la decisión es en dos etapas. Las reglas de política se evalúan en orden de prioridad, y la primera regla que coincide nombra una tabla que consultar; esa tabla hace entonces la coincidencia de prefijo más larga. Una regla puede coincidir por origen, destino, marca de cortafuegos, interfaz o una combinación, y por eso un volcado de la tabla principal puede ser perfectamente exacto y completamente irrelevante para el paquete que investiga.

ip rule show
ip route show table all | head -40
ip route show table 100

Si una regla envía el tráfico de su grupo VPN a la tabla 100, entonces la tabla 100 es la que importa, y la tabla principal es un señuelo. Este es también el mecanismo detrás del enrutamiento basado en origen en un enrutador: el mismo destino puede tener dos respuestas distintas según de dónde venga el paquete, y solo la consulta con un argumento de origen revela cuál se aplica.

IPv6 tiene sus propias reglas y tablas. Un diseño que ejecuta ambas familias necesita ambas consultas, y una respuesta IPv4 que funciona no dice nada sobre la ruta v6 que un cliente de doble pila puede preferir.

Qué instala el cliente VPN

Los clientes normalmente no reemplazan la ruta predeterminada, porque hacerlo rompería la propia ruta exterior del túnel. Instalan algo más específico que gana por longitud de prefijo: un par de medias rutas predeterminadas que cubren 0.0.0.0/1 y 128.0.0.0/1 es el truco clásico, ya que ambos son prefijos más largos que 0.0.0.0/0 y juntos cubren todo el espacio. Otros instalan prefijos privados concretos más una regla de política, y algunos añaden una marca para que solo se capture el tráfico seleccionado.

Por eso "la VPN no cambió mi ruta predeterminada" no es prueba de fallo. Compruebe qué añadió de hecho y si el destino en cuestión cae dentro de esos prefijos:

ip route show | grep -E 'tun|wg|ppp|ipsec'
ip route get 10.20.30.40 from 10.80.0.25

Dos medias rutas son fáciles de pasar por alto en un volcado porque no parecen una ruta predeterminada. Una configuración de túnel dividido que olvidó incluir un prefijo produce exactamente el síntoma que persigue: la aplicación que debería usar el túnel resuelve y se conecta localmente en su lugar. Compare los prefijos instalados con los destinos que el usuario realmente necesita, no con las direcciones que probó por casualidad. Una lista de túnel dividido que cubre el servidor de archivos pero no su resolución produce una conexión que resuelve a una dirección pública y luego falla la autenticación, lo que parece un problema de contraseña y es un problema de ruta.

La ruta exterior también tiene que sobrevivir

El túnel es a su vez tráfico. Los paquetes que llevan la carga encapsulada van a la dirección del par por la interfaz física, y esa ruta no debe enrutarse de vuelta al túnel. Cuando lo hace, se obtiene el fallo característico en el que el túnel se establece y luego deja de pasar tráfico, porque el transporte del túnel está ahora dentro del túnel.

Compruebe la dirección del par tal como comprobó el destino interior, y confirme que resuelve a la interfaz física en lugar del túnel:

ip route get 203.0.113.10
traceroute -n -m 5 203.0.113.10

Una ruta recursiva, una regla de política que atrapa al par o una ruta predeterminada reemplazada por un cliente de túnel completo son las tres causas habituales. Las tres son visibles en la consulta exterior, y ninguna es visible en un volcado de la tabla principal tomado a posteriori.

Qué no puede decirle la salida de enrutamiento

Una consulta correcta significa que el kernel enviaría el paquete a un lugar sensato. No significa que el cortafuegos lo permita, la política IPsec lo cubra, la regla NAT lo traduzca o el lado remoto tenga una ruta de retorno. Cada una de ellas es una etapa posterior, y las notas de reenvío de strongSwan describen la cadena que un paquete debe atravesar en ambos extremos.

Tampoco tiene en cuenta el enlace a nivel de aplicación. Un proceso puede enlazarse a una interfaz, establecer una marca o usar su propio resolutor y conectarse con un nombre que resuelve de forma distinta a lo que probó. Cuando la consulta es correcta y la conexión sigue fallando, la siguiente pregunta es qué proceso la realiza y si ese proceso ve la misma tabla que usted.

Así que mantenga el diagnóstico ordenado: nombre el destino y el origen, ejecute la consulta, lea solo la tabla y la regla que la consulta nombró, y luego pruebe la etapa siguiente. Esa secuencia mantiene una investigación de enrutamiento en minutos y deja un registro que otra persona puede seguir, algo que una tabla pegada nunca hace.