Por qué una ruta de host /32 mantiene accesible el extremo del VPN

Abres la tabla de rutas tras conectarte y encuentras una sola dirección enrutada por el túnel mientras la subred que la rodea sigue yendo a la puerta de enlace local. Esa entrada es una ruta de host: una dirección, emparejada por un prefijo de todo unos. Importa porque las decisiones de enrutamiento usan el prefijo coincidente más largo, así que una /32 puede imponerse a una /24 o a una ruta por defecto sin cambiar ninguna de las dos. Que eso sea una excepción cuidadosa o una futura caída depende de qué dirección nombra y de quién la mantiene.

Una dirección, una entrada en la tabla

Una ruta de host IPv4 lleva un prefijo /32 y una ruta de host IPv6 lleva /128, lo que significa que la entrada puede coincidir exactamente con una dirección de destino. Nada más en la tabla se mueve: la subred que la cubre y la ruta por defecto se quedan donde estaban. La entrada estrecha gana para esa dirección porque su prefijo es más largo, no porque se añadiera después.

Esa propiedad hace de una ruta de host una buena excepción y una mala costumbre. Dos entradas /32 que nombran la puerta de entrada de un servicio no cubren su segunda dirección, su dirección IPv6 ni la dirección a la que se muda el mes que viene. Una tabla llena de entradas de una sola dirección sin explicar suele significar que alguien siguió parcheando alrededor de una decisión de subred en lugar de tomarla. Lee primero la longitud del prefijo y luego pregunta qué debe proteger la entrada.

Lee la entrada desde el cliente hacia fuera

Empieza por la máquina con el problema, porque la misma dirección puede enrutarse de forma distinta en un portátil y en la puerta de enlace que tiene delante. Pregunta al núcleo qué camino elegiría para la dirección exacta que usa la aplicación, en lugar de leer la tabla desde arriba. La respuesta incluye la interfaz y el siguiente salto, que juntos son la decisión.

ip route get 203.0.113.25
ip -6 route get 2001:db8:4::25
ip route show | grep -F 203.0.113.25
Find-NetRoute -RemoteIPAddress 203.0.113.25

Repite la consulta para la familia de direcciones que la aplicación elige realmente, ya que un cliente puede preferir IPv6 y saltarse en silencio una excepción IPv4. Compara el resultado antes y después de que suba el túnel, y guarda ambas salidas. Esa comparación muestra si el cliente añadió la entrada al conectar o si ya estaba ahí.

Una entrada persistente y una entrada de ejecución fallan de forma distinta. La de ejecución desaparece con la sesión, mientras que la persistente sobrevive a un reinicio y sigue enviando tráfico a una puerta de enlace que ya no existe.

La excepción del extremo y la trampa de la recursión

Los clientes de VPN suelen instalar una ruta de host a la dirección exterior del servidor a través de la puerta de enlace original antes de redirigir la ruta por defecto. Sin esa entrada, los paquetes cifrados se enviarían dentro del túnel que intentan construir, y la conexión entraría en bucle hasta agotar el tiempo.

La trampa aparece cuando las subredes aceptadas del túnel incluyen por casualidad esa dirección del extremo, o cuando un segundo perfil añade después una ruta más amplia. La entrada del extremo pierde entonces frente a un prefijo más largo y la sesión se derrumba en cuanto empieza a pasar tráfico. Escribir la dirección del extremo junto a las subredes aceptadas es la forma más barata de notar la colisión antes que los usuarios. También explica por qué el mismo perfil funciona desde una red y falla desde otra.

Verifica el camino que la aplicación usa de verdad

Un ping correcto al nombre del host es una prueba débil cuando la aplicación se conecta a otra dirección u otra familia. Verifica la combinación exacta de dirección, familia, puerto e interfaz desde la máquina que ejecuta el cliente.

ip route get 203.0.113.25
sudo nft list ruleset | grep -A 4 'chain output'
curl -sS --max-time 8 -o /dev/null -w '%{remote_ip}
' https://app.example.net

Si el camino es incorrecto, decide si el requisito es una red o una dirección antes de editar nada. Un requisito de una sola dirección justifica una ruta de host con un comentario y un responsable; un servicio con direcciones rotatorias necesita enrutamiento basado en dominio o una decisión honesta de subred.

Elimina las entradas que ya no correspondan a un destino real y anota las que conserves. Una /32 sin explicar es indistinguible de un error tres meses después, y la siguiente persona la borrará sin saber de qué dependía.