La métrica de la ruta VPN cambia tras conectarse: qué significa
Una métrica más baja solo desempata entre rutas igual de específicas. Lee la regla de política, el prefijo y la ruta de host del extremo antes de editar cualquier número de ruta VPN.
Conectas la VPN, ejecutas route print y la ruta predeterminada ahora lleva una métrica mucho más baja que antes. La conclusión natural es que la VPN tomó la ruta predeterminada porque su número es menor. A veces eso es exactamente lo que ocurrió. A menudo la métrica no es el factor decisivo en absoluto, y editarla no cambia nada porque la elección se hizo antes, por la longitud del prefijo o por una regla de política.
El síntoma es real: el tráfico que antes salía por el adaptador Wi-Fi ahora sale por el túnel, o al revés. La métrica es una entrada de una búsqueda que se ejecuta en un orden fijo, y ese orden es lo que hay que leer antes de tocar un número.
Con qué compite realmente el número
La primera comparación es la especificidad, no la preferencia. Una ruta para 10.20.0.0/16 gana a 10.0.0.0/8, y ambas ganan a 0.0.0.0/0, digan lo que digan sus métricas. Una VPN que instala una ruta predeterminada con la métrica más baja de la máquina sigue perdiendo frente a cualquier ruta más específica que coincida con el destino, incluida la ruta de host que el cliente instala para su propio servidor.
Por eso bajar la métrica de una ruta predeterminada no puede forzar una subred conectada directamente hacia el túnel. Si quieres esa subred dentro de la VPN, añade una ruta para el prefijo o selecciona la tabla del túnel con una regla de política. La métrica es la palanca equivocada para ese trabajo.
| Check in this order | Question | Where you read it |
|---|---|---|
| 1. Policy and table | Which routing table does this traffic use? | ip rule, client profile |
| 2. Prefix length | Which matching route is most specific? | route print, ip route |
| 3. Metric | Which of the equally specific routes is preferred? | route print, ip route |
| 4. Interface state | Is the chosen next hop reachable? | adapter status, link state |
Linux decide la tabla antes que la métrica
En Linux el núcleo consulta primero la base de políticas. ip rule lista las reglas y las tablas que seleccionan, y ip route get 203.0.113.10 informa de la tabla, la ruta y la dirección de origen que el núcleo usaría realmente para ese destino. Una métrica dentro de la tabla 100 nunca compite con una ruta de la tabla principal, porque la regla eligió la tabla antes de que se comparara ninguna métrica.
Por eso una ruta puede verse correcta en ip route show table all y aun así no llevar tráfico. Lee la regla que coincidió, luego la tabla que seleccionó, luego compara las rutas dentro de ella. Si se seleccionó la tabla equivocada, ninguna edición de métrica en la otra tabla ayudará.
Windows combina dos métricas
Windows no tiene base de políticas por defecto, pero combina una métrica de ruta con una métrica de interfaz, y la métrica automática de la interfaz puede cambiar con la velocidad del enlace y el estado del adaptador. Por eso la misma ruta puede comportarse distinto después de que aparezca una estación de acoplamiento o un adaptador virtual. Find-NetRoute -RemoteIPAddress 203.0.113.10 informa de la dirección de origen, el siguiente salto y la interfaz elegidos, lo que está más cerca de la decisión real que la tabla en bruto.
Lee los valores de ruta y de interfaz juntos. Subir la métrica de una interfaz puede mover el tráfico sin que cambie ninguna entrada de ruta, y un cliente VPN que posee sus rutas las reinstalará al reconectar y descartará tu edición.
Mantén el extremo del túnel fuera del túnel
Todo túnel necesita un camino hasta su propio servidor que no pase por el túnel. Los clientes instalan una ruta de host para el extremo a través de la puerta de enlace física, y esa ruta debe seguir siendo más específica que la predeterminada que añade el cliente. Bórrala, o haz que el túnel gane la búsqueda para esa dirección, y los paquetes encapsulados intentarán entrar en el túnel que se supone que deben construir. La conexión falla o entra en bucle.
Comprueba esa ruta de host antes y después de cualquier cambio de métrica: debe apuntar al siguiente salto físico y sobrevivir a una reconexión. Si el cliente la posee, cambia el perfil o la configuración gestionada en lugar de un valor de ejecución que se sobrescribirá.
Comprueba ambas familias de direcciones y el contexto de la aplicación
IPv4 e IPv6 son decisiones separadas con tablas separadas. Una VPN puede llevar IPv4 mientras IPv6 sigue usando el router local, y un cambio de métrica en una familia no dice nada de la otra. Comprueba ambas y luego comprueba el contexto de la aplicación. Un proceso ligado a una interfaz, un espacio de nombres de contenedor o una VPN por aplicación pueden ver una tabla distinta a la de tu shell.
Verifica con la herramienta que informa de la decisión para el destino real, no con el listado completo de la tabla. Si la ruta elegida es la que pretende el diseño, detente. Una métrica que no es el número más pequeño de la pantalla no es un fallo, y forzarla a serlo puede romper el camino del extremo del que depende el túnel.