Subred descendente frente al VPN de escritorio: excluye el tránsito, no las aplicaciones

Una máquina, dos trabajos, un cortafuegos: un enlace ascendente Wi-Fi, una pequeña subred Ethernet detrás y un cliente VPN de escritorio que supone que todo lo que sale del equipo es local. Las aplicaciones iniciadas localmente salen por la ruta de salida local. Los dispositivos detrás de la estación de trabajo llegan por el puerto Ethernet y necesitan una decisión de reenvío. Una exclusión escrita para la primera ruta nunca ve la segunda, y por eso un navegador evita el túnel mientras que los dispositivos no.

Dos rutas de paquetes, una política

La primera fila es lo que describen la mayoría de las guías de split-tunneling. La segunda es una configuración de enrutador que casualmente vive en la misma máquina. Fusionarlas en un solo modelo mental es el error; comparten núcleo, pero no política. Dibuja ambas rutas antes de editar cualquier regla, y el resto del diseño se desprende de qué ruta falta.

La tabla también explica por qué una máquina puede pasar una prueba y fallar otra. El navegador en la estación de trabajo demuestra la ruta local; un portátil conectado al puerto Ethernet demuestra la ruta de reenvío. Valida cada cambio con ambos, o el segundo quedará sin probar por muchas veces que recargues el navegador.

Qué clasifica realmente una exclusión de aplicación

Una exclusión por aplicación suele funcionar marcando los paquetes de un proceso o de un usuario y luego encaminando el tráfico marcado fuera del túnel. Eso es una construcción de salida local. Un paquete de un dispositivo descendente no tiene proceso local, así que nunca coincide con el selector, sea cual sea el selector.

Sea cual sea el selector, las dos listas no son la misma lista, y ahí está todo. La guía de Mullvad para Linux describe marcas que consumen su cortafuegos y su política de enrutamiento, y sus ejemplos apuntan a la salida local; no son una descripción admitida de un enrutador descendente. Copiarlas produce una máquina que cree tener una exclusión mientras reenvía todo al túnel.

Escribe el contrato de tránsito

Nombra a la vez el prefijo de origen descendente y la interfaz de entrada, y luego restringe ese prefijo en la entrada. Sin la restricción, cualquier dispositivo que alcance el puerto puede reclamar una dirección excluida y salir por la omisión. Trátalo como dos preguntas: ¿pueden estos hosts usar este enlace ascendente y pueden alcanzar la estación de trabajo o los rangos privados del túnel? Son permisos adicionales, no efectos secundarios de elegir el enlace.

Permite el reenvío y luego fíltralo. La puerta de enlace Linux necesita el reenvío activado, reglas que permitan el tráfico previsto en ambos sentidos y, o bien una ruta de retorno ascendente, o bien una traducción de origen deliberadamente acotada. NAT por sí solo no selecciona el enlace ascendente ni concede paso por un filtro; solo reescribe una dirección después de esas decisiones.

La clasificación para el tránsito debe ocurrir antes de la decisión de ruta de reenvío, es decir, en la etapa de prerouting y no en output. Una regla colocada después de la decisión aún puede cambiar el paquete, pero no puede cambiar adónde ya se envió.

Las marcas pertenecen a la aplicación que las posee

Los valores de marca, los números de tabla y las prioridades de cadena forman parte de la política de la aplicación VPN, no son constantes eternas. Una red duradera que dependa de insertar una regla en una tabla que otro programa regenera se romperá en la próxima actualización, normalmente durante una reconexión y no en un momento oportuno.

Añadir una segunda cadena base con un veredicto accept no anula necesariamente el drop de una cadena posterior. Las cadenas base tienen ganchos y prioridades, y gana el primer veredicto del orden; un accept en una cadena no cancela un drop al que otra cadena llega antes. Mira el conjunto de reglas completo y el orden de la política de enrutamiento, no el único contador que se incrementó. Un contador demuestra que una regla se ejecutó, nunca que su veredicto fuera el aplicado.

Integra, o mueve la subred

Los dos diseños difieren en quién posee la omisión. Un diseño integrado mantiene una máquina y una política, a costa de depender del ciclo de vida de las tablas de la aplicación VPN y de un conjunto de marcas que su documentación puede cambiar. Un enrutador dedicado para la red descendente elimina esa dependencia por completo: la subred tiene su propio enlace ascendente y la estación de trabajo sigue siendo un cliente sin papel de reenvío.

Elige el segundo cuando la red descendente deba seguir funcionando a través de actualizaciones del VPN, o cuando nadie pueda probar la política integrada tras cada versión. Elige el primero solo cuando la integración esté documentada y alguien se haga cargo de ella.

Verifica la frontera en cuatro estados: conectado, reconectando, bloqueado deliberadamente y detenido. Comprueba la resolución de nombres y ambas familias de direcciones en cada uno, porque una omisión que filtra DNS no es la exclusión que diseñaste. La prueba debe demostrar la frontera precisa, no solo que una página se cargó.