Por qué una subred sigue evitando la ruta predeterminada de la VPN

Cambias la VPN a túnel completo, casi todo el tráfico obedece, y entonces una dirección responde directamente: una impresora, un NAS, un host de salto en 10.x. La lectura obvia es que el túnel tiene una fuga, así que bajas la métrica de la ruta predeterminada y no cambia nada. Ese intento fallido es la pista: una ruta predeterminada es un respaldo, no un veredicto. La consulta de enrutamiento toma el prefijo coincidente más largo antes de comparar siquiera métricas, así que una /24 sigue ganando a una /0 hagas lo que hagas con el número que pongas en cualquiera de ellas. Una vez claro ese orden, la fuga suele ser una ruta que alguien instaló a propósito, o un prefijo que el cliente nunca pretendió cubrir.

Qué promete realmente una ruta predeterminada

0.0.0.0/0 coincide con cualquier destino IPv4 con cero bits de especificidad. Existe para que un host alcance cualquier cosa que su tabla no describa mejor. Una ruta a 192.168.1.0/24 lleva 24 bits coincidentes, así que para 192.168.1.40 gana antes de que nadie compare métricas, distancia administrativa o como quiera que el cliente llame a su campo de prioridad. La misma regla vale en la FIB de Linux, la tabla de enrutamiento de Windows y la pila BSD detrás de macOS.

En una LAN normal ese comportamiento es una virtud. La subred local está conectada directamente, la impresora sigue funcionando mientras el túnel lleva tu navegación, y nada está mal configurado. La pregunta que merece la pena no es por qué esa dirección va directa, sino qué prefijo de qué tabla coincide con ella y quién lo puso ahí.

Medias rutas predeterminadas, o por qué la entrada predeterminada puede parecer intacta

El ejemplo más limpio es redirect-gateway def1 de OpenVPN. En lugar de borrar tu ruta predeterminada y sustituirla, añade 0.0.0.0/1 y 128.0.0.0/1. Juntas, la pareja cubre todo IPv4, cada prefijo es más largo que /0, y ambas superan la ruta predeterminada del router dejándola en su sitio. Ejecuta un listado de rutas después y la ruta predeterminada original sigue ahí, sigue apuntando a tu puerta de enlace; simplemente nunca se elige para destinos de internet.

El wg-quick de WireGuard llega al mismo resultado mediante enrutamiento por políticas. Con AllowedIPs cubriendo 0.0.0.0/0 crea su propia tabla, envía allí los paquetes marcados y añade una regla que ignora el prefijo de longitud cero de la tabla principal. La tabla principal conserva su entrada predeterminada, y las reglas deciden que la tabla del túnel se consulte primero para el tráfico que posee la interfaz.

Ambos diseños necesitan exactamente una ruta fuera del túnel: una ruta de host a la dirección propia del servidor VPN a través de la puerta de enlace original. Sin ella, el cliente intentaría llevar los paquetes que construyen el túnel dentro del túnel, y la conexión nunca se completaría. Una ruta que no es de túnel en tu tabla es, por tanto, normal incluso en un perfil estricto de túnel completo. Las rutas que merecen cuestionarse son las que cubren destinos que de verdad te importan.

Las métricas deciden empates, los prefijos deciden ganadores

Las métricas solo se comparan entre candidatos que coinciden igual de bien con el destino. En Linux, ip route get 10.20.5.9 imprime el ganador junto con su tabla, y ip route show table all lista los candidatos, incluidas las medias rutas predeterminadas y cualquier tabla a la que apunte una regla. En Windows, Find-NetRoute -RemoteIPAddress 10.20.5.9 devuelve la ruta seleccionada y la dirección de origen, mientras que Get-NetRoute muestra la tabla en bruto — pero el coste efectivo es la métrica de ruta más la métrica de interfaz, así que un adaptador lento puede perder un empate que parece ganar.

Tres casos cubren la mayor parte de lo que verás:

• Mismo destino, /24 contra /0: la /24 gana por longitud de prefijo, digan lo que digan las métricas.
• Mismo destino, dos /24 con métricas distintas: gana la métrica efectiva más baja.
• Mismo destino, dos tablas, una elegida por una regla de política: la regla elige primero la tabla, y la comparación de prefijos ocurre dentro de ella.

El tercer caso es donde acaban la mayoría de estos informes. Una ip rule de Linux o un filtro de tráfico VPN de Windows puede enviar tráfico a una tabla que nunca tuvo la ruta predeterminada del túnel, y la tabla principal parece perfecta todo el tiempo.

Quién suele ser dueño de la evasión

Empieza por el perfil, no por la tabla. Las configuraciones de túnel dividido y los ajustes de VPN por aplicación dejan deliberadamente prefijos con nombre fuera del túnel; un perfil de trabajo que protege una subred privada y deja que la navegación general vaya directa se comporta como se diseñó, y anularlo rompe la política que debía aplicar. La guía de enrutamiento VPN de Microsoft traza la misma línea entre tráfico forzado por el túnel y excepciones explícitas, lo que la convierte en una comprobación cruzada útil antes de editar nada.

Después busca restos. Una ruta que apunta a una interfaz que ya no existe, o a una dirección de la red anterior, aparece después de que estaciones de acoplamiento, adaptadores USB y puentes de contenedores vayan y vengan. Borrarla una vez no es el final: los perfiles de conexión de NetworkManager, los archivos netplan y las rutas persistentes de Windows la reinstalan en la siguiente conexión o arranque, así que encuentra el archivo o perfil que la posee antes de editar nada.

Luego comprueba IPv6 por separado. ip -6 route y Get-NetRoute -AddressFamily IPv6 mantienen estado separado, rutas predeterminadas separadas y comportamiento de cliente separado. Una auditoría solo de IPv4 no dice nada sobre un host de doble pila que prefiere en silencio una ruta IPv6 nativa, y eso solo puede hacer que un cliente parezca de túnel dividido.

Confirma con el flujo real de la aplicación

Anota el destino que la aplicación usa realmente y luego pregunta al sistema por la ruta que tomaría desde la dirección de origen a la que se ata esa aplicación. ip route get 10.20.5.9 from 192.168.1.40 responde eso en Linux; Find-NetRoute -RemoteIPAddress 10.20.5.9 más la dirección local lo hace en Windows. Compara el resultado con lo que afirma el perfil. La página de IP pública de un navegador prueba un destino con un protocolo y no dice nada sobre la dirección privada que inició la queja.

Corrige el objeto más estrecho que explique la diferencia. Si la excepción está aprobada, anota el prefijo y déjalo; si no, elimina la ruta o añade una ruta explícita más estrecha por el túnel en lugar de bajar la métrica de la predeterminada. Bajar una métrica no puede superar a un prefijo más largo, y editar la predeterminada mientras dos rutas /1 poseen la ruta de internet tampoco cambia nada.

Luego reconecta el túnel y repite la misma consulta. Los clientes reinstalan rutas en cada conexión, así que un cambio que solo dura hasta el siguiente handshake no está probado. Si la ruta sigue divergiendo, los sospechosos restantes son una regla de política, una segunda tabla o un filtro del lado del cliente: no la ruta predeterminada.

• Nombra el destino y la dirección de origen que la aplicación usa realmente.
• Muestra la ruta ganadora con ip route get o Find-NetRoute.
• Comprueba si un par /1 o una tabla de política posee la ruta de internet.
• Enumera cada prefijo más largo que /0 que coincida con el destino.
• Repite la comprobación de IPv6 por separado.
• Rastrea la ruta superviviente hasta el archivo, perfil o filtro que la instala.
• Reconecta y vuelve a ejecutar la consulta antes de darlo por corregido.

Si los siete coinciden con el perfil, el túnel hace exactamente lo que estaba configurado para hacer, y el arreglo pertenece al perfil y no a una métrica.