Unha aplicación ligada a unha interface? A súa ruta VPN non é a predeterminada

Unha aplicación da máquina sae pola VPN e outra non, e os dous usuarios xuran que non cambiaron nada. A diferenza adoita ser unha decisión de ligazón que toma a propia aplicación: un socket atado a un dispositivo, un enderezo de orixe escollido antes da conexión ou un espazo de nomes coa súa propia táboa de encamiñamento. Cada unha cambia que ruta se aplica, e ningunha aparece nunha comprobación xenérica de IP no navegador.

Tres ligazóns distintas, tres efectos distintos

Ligarse a un dispositivo e ligarse a un enderezo de orixe son operacións relacionadas con consecuencias distintas. Unha ligazón a dispositivo pode forzar o tráfico a saír por unha interface e saltar a busca normal de ruta dese socket. A ligazón a un enderezo de orixe segue pasando pola selección de ruta, pero a orixe escollida pode coincidir cunha regra de política e enviar o paquete a outro sitio. A distinción soa académica ata que unha regra encamiña por orixe. Entón decídeo todo.

O espazo de nomes de rede é o terceiro caso. Ten as súas propias interfaces e a súa propia táboa de encamiñamento, así que unha aplicación dentro non recibe ningún efecto do valor predeterminado do host. Tratar os tres como o mesmo produce explicacións seguras que non superan a primeira proba.

Determine que configura realmente a aplicación

Lea a configuración de rede da aplicación ou o seu comportamento documentado antes de tocar rutas. Se ofrece unha escolla de interface, un campo de enderezo de orixe ou unha opción de espazo de nomes, ese axuste é o primeiro que hai que inspeccionar. Se non, a ligazón pode ser interna e só visible mediante trazado ou os seus propios diagnósticos.

En Linux, opcións de socket como SO_BINDTODEVICE teñen alcance e requisitos de permisos documentados, e un proceso sen privilexios pode non poder establecelas en absoluto. Esa restrición é unha pista útil: se a opción non se pode aplicar, probablemente a aplicación non sexa a orixe da diferenza.

O encamiñamento por políticas le a orixe

Cando hai encamiñamento por políticas configurado, unha regra pode escoller unha táboa segundo a orixe do paquete. Por iso un socket que liga un enderezo de orixe pode seguir unha regra que a ruta predeterminada nunca toca, aínda que non se nomease ningunha interface explicitamente.

Reproduza a busca coa mesma familia de enderezos, orixe e espazo de nomes que usa a aplicación. Unha busca xenérica de ruta desde un intérprete no espazo de nomes do host responde a outra pregunta, e ese desaxuste é o motivo máis habitual de que unha ruta que funciona pareza rota.

Túnel dividido e procesos auxiliares

O túnel dividido por aplicación engade outra capa. O cliente pode coincidir co paquete ou o proceso da aplicación, e un auxiliar que abre o seu propio socket é un suxeito aparte. Un lanzador e o seu servizo en segundo plano poden producir conexións distintas co mesmo nome visible.

Comprobe se a regra de túnel dividido cobre o proceso que realmente se conecta. Se a aplicación se liga a unha interface concreta e o cliente VPN coincide por paquete, as dúas decisións poden discrepar sen que ningunha sexa incorrecta.

Probe o camiño propio da aplicación

Executa unha petición nova desde a aplicación despois de cada cambio. Un navegador que mostra a saída que vostede quería non é unha proba equivalente para outro programa ligado a outra interface, e as conexións na caché poden seguir usando a ruta antiga moito despois de cambiar un axuste. Peche a sesión antiga antes de xulgar a regra nova. Se non, a proba mide o pasado.

A referencia de sockets de Linux documenta SO_BINDTODEVICE e os seus requisitos. Lea primeiro a configuración da propia aplicación, reproduza a busca no mesmo contexto e só despois decida se hai que cambiar a ruta ou a ligazón.