Salida separada: pool de VPN por usb0, tráfico de la puerta de enlace por eth0

Los clientes se conectan y se autentican, y luego su tráfico sale por el enlace ascendente equivocado, porque la única ruta predeterminada del equipo pertenece a la propia puerta de enlace. Reemplazar esa ruta predeterminada rompería las actualizaciones y el acceso de administración de la máquina, así que la selección debe ser más estrecha que «todo el tráfico». La forma viable es una regla de política basada en la dirección de origen interna del pool de clientes, que apunta a una segunda tabla de enrutamiento dueña del WAN alternativo. A partir de ahí, la lista de comprobación trata de completitud y de comportamiento ante fallos, no de la regla en sí.

Confirma que la dirección de origen sobrevive hasta la decisión de enrutamiento

Una regla de política que coincide con un rango de origen solo se activa cuando el paquete todavía lleva ese origen en el momento de la consulta. El tráfico de clientes reenviado lo hace, siempre que nada aguas arriba lo haya reescrito antes del enrutamiento. El tráfico generado por la puerta de enlace no lo hace, y por eso mismo su propia ruta predeterminada puede quedarse donde está.

Aquí es donde las pruebas locales engañan. Un curl ejecutado en la puerta de enlace es un flujo generado localmente con la dirección de la puerta de enlace, así que toma la tabla principal y no demuestra nada sobre la ruta del cliente. Prueba desde un cliente conectado o genera tráfico con un origen que realmente pertenezca al pool.

Empieza anotando los valores reales: el prefijo del pool, la interfaz de túnel que lo transporta, la dirección y el siguiente salto del segundo WAN, y el número de tabla que piensas usar. Limpia las reglas antiguas de cualquier intento anterior antes de añadir nuevas, porque las reglas duplicadas con prioridades distintas producen fallos que parecen aleatorios.

Construye una tabla seleccionada que esté completa

Una tabla no es una ruta predeterminada con un amigo. Necesita suficientes rutas para que cada consulta se resuelva dentro de ella, incluida la ruta conectada de la subred WAN para que el siguiente salto sea alcanzable. Para un pool de 10.77.0.0/24 en tun1, una dirección WAN de 203.0.113.20/24 con siguiente salto 203.0.113.1, y la tabla 600:

ip -4 route replace 203.0.113.0/24 dev usb0 src 203.0.113.20 table 600
ip -4 route replace 10.77.0.0/24 dev tun1 table 600
ip -4 route replace default via 203.0.113.1 dev usb0 table 600
ip -4 rule add priority 1500 from 10.77.0.0/24 lookup 600

La regla se sitúa en una prioridad por debajo de cualquier regla comodín existente, así que los clientes coincidentes llegan primero a la tabla 600 y todo lo demás cae a la tabla principal. La referencia de ip-rule describe por completo el modelo de consulta ordenada y la sintaxis del selector.

Después piensa en lo que la tabla no contiene. Un destino que solo tiene ruta en la tabla principal, como una subred de administración accesible por eth0, no se encontrará en la tabla 600 y no volverá a la principal una vez que exista allí una ruta predeterminada. Si esos caminos importan, añádelos explícitamente a la tabla seleccionada, que suele ser la respuesta correcta para una tabla de salida VPN.

Mantén el tráfico propio del escucha fuera de la política

El escucha de OpenVPN tiene su propia conexión externa, transportada por el enlace ascendente por el que el cliente lo alcanzó. Ese tráfico debe conservar el camino de vuelta con el que llegó, y una regla amplia que cubra la dirección pública del servidor o toda la interfaz de túnel puede arrastrarlo a la tabla alternativa. Limita la regla al pool interno y a nada más.

El filtrado de ruta inversa merece un vistazo por el mismo motivo. Cuando las respuestas a los clientes salen por usb0 mientras la petición llegó por otro enlace, un ajuste estricto de rp_filter puede descartar paquetes que la política de enrutamiento considera válidos. Comprueba los valores efectivos de sysctl en ambas interfaces antes de concluir que la regla ha fallado.

El orden también importa respecto a cualquier otra cosa del equipo. Los puentes de Docker, un segundo VPN y cualquier regla previa de una imagen de proveedor añaden prioridades, así que lee la lista completa de reglas en lugar de suponer que la prioridad 100 está sola.

Haz que el reenvío y la traducción concuerden con la ruta

El enrutamiento elige un enlace ascendente; no concede permiso para reenviar. El núcleo debe tener el reenvío IPv4 habilitado, y el cortafuegos debe aceptar la dirección de cliente a WAN y el tráfico de vuelta. Una tabla correcta con una cadena FORWARD que descarte el flujo produce el mismo síntoma que una ruta ausente, y por eso ambos se comprueban en la misma pasada.

Si el segundo WAN no enrutará un pool privado de vuelta hacia ti, traduce el origen en esa salida. Para una interfaz con dirección dinámica, la elección habitual es una regla masquerade estrecha limitada al pool y a la interfaz:

iptables -t nat -A POSTROUTING -s 10.77.0.0/24 -o usb0 -j MASQUERADE

Aquí el alcance importa más que el objetivo. Una regla masquerade que coincida con cualquier interfaz de salida también reescribirá el tráfico que sale correctamente por eth0, lo que oculta los errores de enrutamiento en lugar de corregirlos. La traducción se ejecuta después de la decisión de enrutamiento, así que nunca puede reparar un paquete enviado al enlace ascendente equivocado.

La sobrecarga del túnel también requiere atención cuando los caminos difieren. Si los clientes negocian un MSS TCP grande y el WAN alternativo tiene una MTU más baja o un túnel dentro, los segmentos grandes se atascan mientras los pequeños funcionan. Limitar el MSS en el camino de reenvío convierte eso en un comportamiento predecible en lugar de un bloqueo intermitente.

Decide qué ocurre cuando usb0 desaparece

Una tabla vacía no es un estado de cierre ante fallos. Si la ruta coincidente desaparece, la consulta continúa hacia la regla siguiente, llega a la tabla principal y toma la ruta predeterminada de eth0. El tráfico que debía salir por el segundo WAN sale en silencio por el primero, lo que en un despliegue con enrutamiento por política suele ser el resultado que menos quieres.

Donde ese repliegue es inaceptable, añade una ruta terminal explícita en la tabla 600, como una ruta predeterminada blackhole, o descarta el pool en el cortafuegos mientras la interfaz está caída. Cualquiera de las dos es una decisión que puedes escribir; el silencio no.

La persistencia es el último punto. Quien posea ambos enlaces, ya sea el gestor de red, un script despachador o el ciclo de vida de la conexión, debe recrear las rutas y la regla en cada reconexión sin añadir duplicados. Verifícalo con una petición de un cliente real y otra separada desde la puerta de enlace, confirma la salida observada en ambas, luego retira el segundo WAN y observa cuál de los dos resultados que diseñaste ocurre realmente. IPv6 necesita su propia tabla, regla y traducción; la regla IPv4 anterior no dice nada sobre ello.