Una aplicación vinculada a la dirección de la VPN sigue usando la ruta incorrecta

Una aplicación se vincula a la dirección de la VPN y, aun así, la conexión sale por la ruta predeterminada habitual. Nada ha fallado en el bind: ha hecho exactamente lo que hace un bind. Vincular un socket a una dirección local elige la dirección de origen que el núcleo pone en la cabecera. No instala una ruta ni crea una regla de política que envíe los paquetes con ese origen a un túnel concreto.

El resto de este manual es el orden de comprobación que uso, junto con el comando que produce cada observación.

Qué decide realmente un bind

Un bind asigna una dirección local al socket. Después el núcleo ejecuta la misma búsqueda de ruta que habría ejecutado de otro modo, salvo que una regla de política cambie qué tabla lee esa búsqueda.

Por eso un paquete puede salir con una dirección de origen de la VPN por una interfaz física. En el otro extremo llega desde un rango privado que la red nunca esperó en ese camino, el tráfico de vuelta no tiene ruta de regreso y la conexión se cuelga o se reinicia.

La referencia de sockets IP de Linux documenta la semántica del bind. La mitad de enrutamiento vive en ip-rule e ip-route, y son páginas de manual separadas por un motivo.

Confirme que la dirección pertenece a este espacio de nombres

Una dirección a la que puede vincularse debe existir en una interfaz dentro del espacio de nombres de red donde se ejecuta la aplicación. Una dirección de par, una dirección de puerta de enlace o una dirección que solo existe en otro espacio de nombres no se puede vincular, y la llamada falla con EADDRNOTAVAIL.

ip -br addr show
ip netns identify <pid>
ss -tanp | grep <port>

Ejecute esos tres en el mismo contexto que la aplicación: mismo espacio de nombres y mismo usuario si puede obtenerlo. Un diagrama net30 antiguo no es prueba de qué dirección asignó su topología actual al cliente. Lea la interfaz que está realmente activa.

Lea la búsqueda para ese origen y ese destino

Un solo comando responde la pregunta que el bind no respondió:

ip route get 203.0.113.10 from 10.8.0.2
ip rule show

La primera línea imprime la ruta que tomaría un paquete desde ese origen hasta ese destino, incluida la interfaz de salida y el origen preferido. Si nombra la interfaz física, el bind y la ruta no coinciden, y el paquete saldrá con un origen al que el camino no puede volver.

Después ip rule show le dice si alguna regla habría elegido otra tabla. Las prioridades importan aquí, porque gana la primera regla que coincide y una regla comodín por encima de la suya hace invisible la suya.

Instale una regla de política solo si ese es el diseño

El enrutamiento basado en el origen es un diseño deliberado, no una reparación para una aplicación. Si el propietario de la política quiere que el tráfico de la subred del túnel use el túnel, la regla pertenece a su configuración y no a un comando puntual en su portátil.

Una forma viable es una tabla dedicada con una ruta predeterminada por el túnel, más una regla que envíe el rango de origen de la VPN a esa tabla. Añada las excepciones que el diseño necesite, porque una tabla que solo contenga un defecto de túnel capturará destinos que deben quedarse locales o ser accesibles por el camino físico.

ip route add default dev tun0 table 100
ip rule add from 10.8.0.2 table 100 priority 100
ip route get 203.0.113.10 from 10.8.0.2

Deshaga con ip rule del e ip route flush table 100. Todo lo añadido así desaparece al reiniciar, salvo que un gestor lo escriba, lo que es a la vez una propiedad de seguridad y un motivo para no guardar la única copia en el historial de su shell.

Verifique con tres observaciones

Anote el origen que pidió la aplicación, la ruta que eligió la búsqueda y el origen que el servidor vio realmente.

Esos tres pueden discrepar, y cada discrepancia apunta a un sitio distinto. Una captura en la interfaz del túnel demuestra que el paquete salió con el origen correcto. Una captura en la interfaz física demuestra que salió por el camino equivocado. La vista del lado del servidor es la única que demuestra el camino de extremo a extremo.

Si la aplicación ofrece una opción de vinculación a un dispositivo o un modo de enrutamiento por aplicación, trátela como un mecanismo distinto con restricciones distintas. Los ajustes de aspecto similar no todos acaban en la misma decisión del núcleo.