Dante SOCKS sobre VPN: túnel completo frente a enrutamiento por origen

Quiere que el tráfico del proxy SOCKS salga por la VPN mientras el resto del host conserva su ruta normal. Dos diseños lo consiguen y se diferencian en qué se rompe cuando algo va mal. Uno empuja una ruta predeterminada dentro del túnel y luego la sortea; el otro deja la tabla principal intacta y envía una sola dirección de origen a una segunda tabla. El segundo es más limpio y tiene sus propias trampas.

Dos diseños, dos radios de daño distintos

El diseño de túnel completo es lo que hacen por defecto la mayoría de los clientes VPN: sustituir la ruta predeterminada para que todo siga el túnel y después excluir lo que no debería. Es fácil de razonar y difícil de mantener estrecho, porque cada servicio local que añade hereda el túnel hasta que lo excluye. El modo de fallo es amplio, ya que una sola ruta equivocada se lleva consigo la conectividad del propio host.

El diseño de selección por origen va al revés. La tabla principal se queda como estaba y una regla de política envía los paquetes de una dirección local concreta a una tabla con una ruta predeterminada por el túnel. Nada más cambia, lo que significa que el radio de daño es una dirección.

Esa estrechez es también la restricción: el diseño solo funciona si los paquetes salientes del proxy llevan realmente esa dirección.

Qué hace el ajuste external de Dante

El ajuste external elige las direcciones que el proxy usa para las conexiones salientes; no toca la política de enrutamiento del kernel. Esa separación es la que hace posible el segundo diseño, y también es donde la gente lee mal la documentación. Apuntar external a una dirección del túnel hace que el proxy origine sus conexiones desde esa dirección, y la tabla de enrutamiento decide después adónde van esos paquetes.

El listener es un asunto aparte. Mantenga internal restringido a los clientes que deberían usar el proxy, exija autenticación y corte el puerto con un cortafuegos, porque un listener abierto no es una característica de la salida por VPN.

Confirme que la dirección configurada pertenece de verdad al túnel dentro del espacio de nombres de red del proxy.

Construir la tabla de selección por origen

Para una dirección TUN de 10.90.0.2/24 con un par alcanzable en 10.90.0.1, y un número de tabla que no use nada más, la disposición es esta:

ip -4 route add table 100 10.90.0.0/24 dev tun0 src 10.90.0.2
ip -4 route add table 100 default via 10.90.0.1 dev tun0 metric 10
ip -4 route add table 100 unreachable default metric 32760
ip -4 rule add priority 1000 from 10.90.0.2/32 lookup 100

La ruta inalcanzable es la parte que la gente omite. Sin ella, una tabla cuya ruta de túnel desaparece cae en la ruta predeterminada corriente y el proxy sale en silencio por la WAN. Con ella, la consulta falla, lo que es un fallo visible en lugar de una fuga silenciosa. La prioridad de la regla también tiene que quedar por delante de cualquier otra cosa que coincida con ese origen.

Estos valores describen una topología. Los pares punto a punto, el direccionamiento net30 y los clientes que reparten un prefijo distinto necesitan sus propias rutas, así que copie la forma, no las direcciones.

Dónde pierde la regla de origen

Una regla que coincide con una dirección de origen afecta a todos los procesos que la usan, no solo al proxy. Si otro demonio vincula la misma dirección, su tráfico también toma el túnel y el fallo parecerá un problema de un servicio no relacionado. Dé al proxy una dirección que no use nadie más, o acepte que el alcance es la dirección y no el proceso.

DNS es la otra fuga. Un socket de resolución no usa necesariamente el origen de datos salientes del proxy, así que las consultas de nombres aún pueden salir por la WAN. Pruebe la resolución por separado del establecimiento de la conexión y decida si ese resultado es aceptable.

IPv6 necesita sus propias reglas y rutas, porque una disposición IPv4 no demuestra nada sobre él.

Elija según el fallo que pueda tolerar

Elija el túnel completo cuando el host deba protegerse en conjunto y pueda mantener la lista de exclusiones. Elija el enrutamiento por origen cuando el host deba conservar su propia ruta y solo un servicio deba redirigirse. Ambos son legítimos; el error es elegir uno y luego probarlo como si fuera el otro.

Cualquiera que elija, verifique desde ambos lados: una petición a través del proxy y una petición directa desde el host, con la dirección de salida observada registrada para cada una.

Si el túnel cae, decida de antemano si el proxy debe fallar o volver atrás, y deje que la tabla de enrutamiento exprese esa decisión.