Cómo ejecutar un proceso de Linux fuera de un túnel de WireGuard

No puede eximir a un programa de un equipo WireGuard con túnel completo editando rutas. Las rutas eligen un camino por destino, y lo que quiere eximir es un proceso, así que el núcleo no tiene con qué emparejarlo. El enfoque viable es darle a ese proceso su propio contexto de red: un espacio de nombres con su propia interfaz, sus direcciones y su ruta predeterminada, unido al equipo mediante un par veth. Lo ejecuté en Ubuntu 24.04 con wireguard-tools 1.0.20210914, y el espacio de nombres nunca fue el problema: lo fueron la política de reenvío del equipo y las reglas de marcado del túnel.

Primero elija el tipo de contexto que necesita

En la práctica aparecen dos formas. Si el equipo ejecuta un túnel completo y un programa debe salir por la ruta del ISP, construye un segundo espacio de nombres, lo conecta al equipo y deja que el equipo reenvíe y traduzca el tráfico por él. Si un espacio de nombres ya lleva una interfaz VPN y solo necesita un comando iniciado dentro, ese es el caso simple de ip netns exec y la mayor parte del trabajo de enrutamiento ya está hecha.

Ninguna de las dos formas le da una regla limitada a un solo identificador de proceso. Netfilter empareja direcciones, puertos, marcas e interfaces; no hay tabla de enrutamiento por proceso. El marcado puede dirigir el tráfico, pero la marca debe aplicarse a paquetes que ya identificó, y ese es el mismo problema una capa más abajo. Un espacio de nombres separa toda la pila para ese árbol de procesos, y por eso es la respuesta habitual.

Si el requisito es realmente que nada salga del túnel, detenga el túnel en su lugar. El espacio de nombres existe para el caso mixto: un programa fuera, todo lo demás dentro, en la misma máquina, al mismo tiempo.

Construya el segundo contexto y únalo al equipo

Un diseño ilustrativo: el equipo tiene una interfaz WireGuard que lleva la ruta predeterminada, y un espacio de nombres de red llamado clearnet unido al equipo mediante un par veth. Las direcciones de abajo son ejemplos.

ip netns add clearnet
ip link add veth-clear-out type veth peer name veth-clear-in
ip addr add 192.168.100.1/24 dev veth-clear-out
ip link set veth-clear-out up
ip link set veth-clear-in netns clearnet
ip netns exec clearnet ip addr add 192.168.100.2/24 dev veth-clear-in
ip netns exec clearnet ip link set veth-clear-in up
ip netns exec clearnet ip route add default via 192.168.100.1

Ese espacio de nombres ahora puede llegar al equipo y a nada más. El equipo debe reenviar el tráfico y reescribir la dirección de origen, porque 192.168.100.0/24 es privada y el router upstream no tiene ruta de vuelta hacia ella:

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -o <wan-interface> -j MASQUERADE

Confirme el lado del espacio de nombres antes de seguir.ip netns exec clearnet ip route debería mostrar la ruta veth y la ruta predeterminada a través de 192.168.100.1, y un ping a esa dirección debería responder. Si el ping a la dirección del equipo falla, las direcciones o el estado del enlace están mal y ninguna regla de cortafuegos ayudará.

Cuando los nombres se resuelven pero no vuelve nada, lea FORWARD

El fallo clásico parece un error de enrutamiento: el espacio de nombres resuelve un nombre, el paquete sale y nunca llega una respuesta. En equipos con una política FORWARD de DROP — así lo hacen varias distribuciones y la mayoría de las imágenes endurecidas — el paquete se descarta de camino, y el error que imprime la aplicación no dice nada sobre el filtrado.

Lea la cadena antes de añadir nada:

iptables -S FORWARD
nft list chain inet filter forward

Luego admita el tráfico en ambas direcciones, con contadores, para que pueda ver si la regla llegó a coincidir:

iptables -A FORWARD -i veth-clear-out -o <wan-interface> -j ACCEPT
iptables -A FORWARD -i <wan-interface> -o veth-clear-out -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
watch -n1 'iptables -L FORWARD -v -n'

Una regla con un contador de paquetes a cero no está en el camino. O los nombres de las interfaces difieren de lo que supuso, o una regla anterior de la cadena aceptó, descartó o devolvió el paquete primero. Corrija el orden, no el texto de la regla.

El tráfico de respuesta es la mitad que la gente olvida. La regla de retorno necesita el mismo nombre veth más una coincidencia de estado de conexión, o una aceptación de interfaz simple si mantiene la política abierta. Añada solo la regla de salida y el síntoma original vuelve, con su regla nueva allí y aparentemente correcta.

Mantenga las reglas de marcado del túnel fuera del camino nuevo

Este paso convierte un espacio de nombres que funciona en uno que filtra. Las configuraciones de WireGuard suelen instalar una política de marca de cortafuegos junto con sus propias reglas de enrutamiento y una tabla dedicada, de modo que los paquetes sin marca vuelven a la tabla principal mientras los marcados usan la tabla del túnel. El tráfico reenviado desde el espacio de nombres se evalúa contra el enrutamiento por políticas a la salida y, según cómo se hayan escrito esas reglas, puede caer en la tabla del túnel.

Dos añadidos separan los caminos. Vuelva pronto en la cadena mangle para la subred del espacio de nombres y añada una regla basada en el origen que ponga esa subred en la tabla principal:

iptables -t mangle -I PREROUTING -s 192.168.100.0/24 -j RETURN
ip rule add from 192.168.100.0/24 lookup main priority 100

La prioridad 100 se ordena antes de las reglas del túnel en mi equipo, así que para ese origen decide la tabla normal. No copie el número a ciegas: las prioridades que wg-quick instala difieren entre versiones y entre las configuraciones de IPv4 e IPv6, así que ejecute ip rule show y elija una prioridad que quede delante de las reglas del túnel en su máquina.

Verifique con una búsqueda específica de origen en lugar de confiar en la lista de reglas:

ip route get 1.1.1.1 from 192.168.100.2
ip netns exec clearnet ip route get 1.1.1.1

Si el primer comando informa de la interfaz WireGuard, la regla nueva aún no está delante de la política del túnel. Si informa de la interfaz WAN mientras el segundo sigue mostrando la ruta predeterminada veth, el equipo y el espacio de nombres no coinciden y debería releer ambas tablas de enrutamiento.

Inicie el proceso que abre la conexión

Iniciar el comando es una línea, pero inicie el proceso que crea realmente el socket.ip netns exec clearnet curl -s https://ifconfig.me es la prueba honesta más pequeña: muestra la dirección que el espacio de nombres presenta al mundo, no la que usaría el equipo.

Para un servicio, adjunte el espacio de nombres por ruta para que el proceso permanezca en él toda su vida:

[Service]
NetworkNamespacePath=/run/netns/clearnet

Las aplicaciones gráficas son donde el enfoque de una línea falla en silencio. Un navegador iniciado desde un menú suele entregar la solicitud a una instancia que ya se ejecuta fuera del espacio de nombres, así que aparece la ventana nueva y el tráfico sigue saliendo por el túnel. Deles un perfil separado para que se cree realmente una instancia nueva y luego compruebe el contexto del proceso en lugar de adivinar:

readlink /proc/$(pgrep -f clearnet-profile | head -1)/ns/net
readlink /run/netns/clearnet

Las dos salidas deben coincidir. La misma comprobación sirve para cualquier programa de larga duración, y vale la pena hacerla una vez por aplicación en lugar de suponer que el lanzador hizo lo que usted quería.

La resolución de nombres necesita su propia decisión. Crear un espacio de nombres no le da configuración de resolución; los archivos por espacio de nombres se admiten mediante /etc/netns/<name>/resolv.conf y sin uno hereda un comportamiento que es fácil de leer mal. IPv6 necesita el mismo trato: si el espacio de nombres no tiene ruta predeterminada v6 mientras la aplicación prefiere v6, las solicitudes pueden atascarse antes de retroceder, lo que parece un túnel roto.

Compruebe el encuadre, no solo la dirección de salida

Una dirección pública que funciona demuestra la ruta, no todo el requisito. Recorra el resto en este orden:

• ip netns exec clearnet ip route get 1.1.1.1 muestra la ruta predeterminada veth, no la interfaz WireGuard.
• Los contadores FORWARD de ambas reglas aumentan mientras se ejecuta una solicitud.
• El proceso de la aplicación informa del inodo del espacio de nombres que espera.
• Tras un reinicio el espacio de nombres existe antes de que arranque el servicio; una unidad que se ejecute antes falla o, peor, se ejecuta fuera del espacio de nombres.

Después decida qué debe ocurrir cuando el túnel caiga. El espacio de nombres sigue funcionando, que es el objetivo del ejercicio y también el riesgo: el programa eximido sigue conectado mientras todo lo demás se detiene. Anótelo como una decisión de política y sea claro sobre lo que la exención no cubre: la identidad de la cuenta, el estado guardado del navegador y su proveedor de DNS quedan todos fuera del alcance de un espacio de nombres de red, y tratar la exención como anonimato es el error que sobrevive a la configuración.