Sin interruptor para excluir esta aplicación: dele al proceso su propia fuente

Un programa debería usar la conexión normal mientras todo lo demás permanece en el túnel, y el cliente no tiene ningún interruptor para eso. Tampoco hay ningún menú oculto que encontrar. Una ruta se elige a partir de campos dentro del paquete, y el paquete lleva direcciones y puertos en vez de la identidad del proceso que lo creó, así que una exclusión tiene que expresarse en uno de esos campos. Siga un paquete una vez y las opciones disponibles dejan de ser misteriosas.

Por qué el cliente no puede ofrecerlo

El enrutamiento por destino compara la dirección de destino con prefijos y conserva la coincidencia más larga. En ese momento todo paquete se ve igual, sea cual sea lo que lo produjo. El enrutamiento por política de origen amplía la comparación a la dirección de origen, y ese es el gancho que usa cualquier solución práctica: cambie el origen y otra tabla pasa a ser elegible.

Los puertos no ayudan. Una exclusión por puerto tendría que evaluarse antes de la consulta de destino, y el puerto no desempeña ningún papel en esa decisión. Todo lo que se anuncia como exclusión por puerto en realidad excluye por algún otro campo y lo describe de forma laxa.

El enrutamiento real por aplicación existe donde la plataforma añadió maquinaria para ello, como las llamadas de filtro en Windows o la vinculación del servicio VPN en Android. Una instancia de escritorio de OpenVPN no trae nada de eso, y ninguna opción de configuración lo inventa.

Linux: marque el proceso y luego enrute la marca

El enfoque más limpio ata la decisión al proceso que posee el socket. La coincidencia owner funciona para el tráfico generado localmente en la cadena OUTPUT, así que una marca aplicada allí puede seleccionar una tabla aparte:

iptables -t mangle -A OUTPUT -m owner --uid-owner 1001 -j MARK --set-mark 0x1
ip rule add fwmark 0x1 table 200
ip route add 192.168.1.0/24 dev eth0 src 192.168.1.0 table 200
ip route add default via 192.168.1.1 dev eth0 table 200

Los paquetes del usuario 1001 consultan entonces la tabla 200 y salen por la puerta de enlace habitual, mientras la tabla principal sigue enviando todo lo demás al túnel. La coincidencia owner solo se aplica a paquetes generados localmente, que es exactamente el tráfico que le importa aquí, y no puede clasificar paquetes reenviados para otro host. Verifique con las herramientas y no con la intención: ss -tnp muestra la dirección local y el proceso propietario de las conexiones establecidas, y ip route get 1.1.1.1 mark 0x1 muestra qué tabla selecciona la marca.

Un espacio de nombres de red es la respuesta más sólida para un programa autocontenido, porque cada socket creado dentro queda ligado a él por construcción, así que los procesos auxiliares y las conexiones hijas heredan el comportamiento sin clasificarse en absoluto. El coste es de fontanería: un par veth, una dirección en cada extremo y una ruta por defecto dentro del espacio de nombres que apunta de vuelta al host.

ip netns add novpn
ip link add veth-host type veth peer name veth-ns
ip link set veth-ns netns novpn
ip addr add 10.200.0.1/24 dev veth-host
ip netns exec novpn ip addr add 10.200.0.2/24 dev veth-ns
ip netns exec novpn ip route add default via 10.200.0.1

Windows: el destino sigue decidiendo

Windows elige la interfaz de salida a partir del destino, así que un programa que quiere otro camino tiene que cambiar algo que la pila consulta antes de esa elección. ForceBindIP cubre la primera mitad: inicia un programa con sus sockets ya ligados a una dirección local que usted nombre. Eso por sí solo no cambia por qué interfaz sale el paquete, porque el destino sigue seleccionando la ruta. Ate un origen en un portátil cuya ruta por defecto apunta al túnel y el paquete entra en el túnel de todos modos.

El síntoma tiene una forma legible una vez que lo conoce. Se cumple para una dirección de LAN que la interfaz elegida alcanza directamente y falla para cualquier cosa en internet cuya ruta apunte al túnel. También parece funcionar hasta que el programa pasa trabajo a un auxiliar, porque a un auxiliar que abre su propio socket nunca se le dijo nada del enlace.

Mueva la decisión cuando un solo proceso es la unidad equivocada

Si el requisito real es un dispositivo y no un programa, póngalo en su propio SSID o VLAN y deje que el router decida: esa fuente toma el camino normal mientras las demás usan el túnel. Una máquina de puerta de enlace dedicada es el otro diseño honesto: mantiene la VPN y solo recibe los destinos que el router le envía. En una VLAN la política cubre cada flujo que abre el dispositivo, incluidos los procesos auxiliares que rompieron el enfoque de Windows. El intercambio es de alcance: dos programas en ese dispositivo ya no pueden tratarse de forma distinta.

Ambas son políticas de origen o de destino con un alcance que puede decir en una frase. Ninguna es por aplicación, y un diseño que se vende como por aplicación falla la primera vez que el programa delega su trabajo a un segundo proceso.