¿Una aplicación vinculada a una interfaz? Su ruta VPN no es la predeterminada

Una aplicación de la máquina sale por la VPN y otra no, y ambos usuarios juran que no cambiaron nada. La diferencia suele ser una decisión de vinculación que toma la propia aplicación: un socket atado a un dispositivo, una dirección de origen elegida antes de la conexión o un espacio de nombres con su propia tabla de enrutamiento. Cada una cambia qué ruta se aplica, y ninguna aparece en una comprobación genérica de IP en el navegador.

Tres vinculaciones distintas, tres efectos distintos

Vincularse a un dispositivo y vincularse a una dirección de origen son operaciones relacionadas con consecuencias distintas. Una vinculación a dispositivo puede forzar el tráfico a salir por una interfaz y saltarse la búsqueda normal de ruta de ese socket. La vinculación a una dirección de origen sigue pasando por la selección de ruta, pero el origen elegido puede coincidir con una regla de política y enviar el paquete a otro sitio. La distinción suena académica hasta que una regla enruta por origen. Entonces lo decide todo.

El espacio de nombres de red es el tercer caso. Tiene sus propias interfaces y su propia tabla de enrutamiento, así que una aplicación dentro no recibe ningún efecto del valor predeterminado del host. Tratar los tres como lo mismo produce explicaciones seguras que no superan la primera prueba.

Determine qué configura realmente la aplicación

Lea la configuración de red de la aplicación o su comportamiento documentado antes de tocar rutas. Si ofrece una elección de interfaz, un campo de dirección de origen o una opción de espacio de nombres, ese ajuste es lo primero que hay que inspeccionar. Si no, la vinculación puede ser interna y solo visible mediante trazado o sus propios diagnósticos.

En Linux, opciones de socket como SO_BINDTODEVICE tienen alcance y requisitos de permisos documentados, y un proceso sin privilegios puede no poder establecerlas en absoluto. Esa restricción es una pista útil: si la opción no se puede aplicar, probablemente la aplicación no sea el origen de la diferencia.

El enrutamiento por políticas lee el origen

Cuando hay enrutamiento por políticas configurado, una regla puede elegir una tabla según el origen del paquete. Por eso un socket que vincula una dirección de origen puede seguir una regla que la ruta predeterminada nunca toca, aunque no se haya nombrado ninguna interfaz explícitamente.

Reproduzca la búsqueda con la misma familia de direcciones, origen y espacio de nombres que usa la aplicación. Una búsqueda genérica de ruta desde un intérprete en el espacio de nombres del host responde a otra pregunta, y ese desajuste es el motivo más habitual de que una ruta que funciona parezca rota.

Túnel dividido y procesos auxiliares

El túnel dividido por aplicación añade otra capa. El cliente puede coincidir con el paquete o el proceso de la aplicación, y un auxiliar que abre su propio socket es un sujeto aparte. Un lanzador y su servicio en segundo plano pueden producir conexiones distintas bajo el mismo nombre visible.

Compruebe si la regla de túnel dividido cubre el proceso que realmente se conecta. Si la aplicación se vincula a una interfaz concreta y el cliente VPN coincide por paquete, las dos decisiones pueden discrepar sin que ninguna sea incorrecta.

Pruebe el camino propio de la aplicación

Ejecute una petición nueva desde la aplicación después de cada cambio. Un navegador que muestra la salida que usted quería no es una prueba equivalente para otro programa vinculado a otra interfaz, y las conexiones en caché pueden seguir usando la ruta antigua mucho después de cambiar un ajuste. Cierre la sesión antigua antes de juzgar la regla nueva. Si no, la prueba mide el pasado.

La referencia de sockets de Linux documenta SO_BINDTODEVICE y sus requisitos. Lea primero la configuración de la propia aplicación, reproduzca la búsqueda en el mismo contexto y solo después decida si hay que cambiar la ruta o la vinculación.