Com executar un procés de Linux fora d'un túnel WireGuard

No podeu eximir un programa d'un amfitrió WireGuard amb túnel complet editant rutes. Les rutes trien un camí per destinació, i el que voleu eximir és un procés, així que el nucli no té res amb què aparellar-lo. L'enfocament viable és donar a aquest procés el seu propi context de xarxa: un espai de noms amb la seva pròpia interfície, adreces i ruta per defecte, connectat a l'amfitrió mitjançant un parell veth. Ho vaig executar a Ubuntu 24.04 amb wireguard-tools 1.0.20210914, i l'espai de noms mai va ser el problema — ho van ser la política de reenviament de l'amfitrió i les regles de marcatge del túnel.

Primer trieu el tipus de context que necessiteu

A la pràctica apareixen dues formes. Si l'amfitrió porta un túnel complet i un programa ha de sortir pel camí de l'ISP, construïu un segon espai de noms, connecteu-lo a l'amfitrió i deixeu que l'amfitrió reenviï i tradueixi el trànsit per a ell. Si un espai de noms ja porta una interfície VPN i només necessiteu una ordre iniciada dins seu, aquest és el cas senzill d'ip netns exec i la major part de la feina d'encaminament ja està feta.

Cap de les dues formes no us dona una regla limitada a un sol identificador de procés. Netfilter aparella adreces, ports, marques i interfícies; no hi ha cap taula d'encaminament per procés. El marcatge pot dirigir el trànsit, però la marca s'ha d'aplicar a paquets que ja heu identificat, i aquest és el mateix problema una capa més avall. Un espai de noms separa tota la pila per a aquell arbre de processos, i per això és la resposta habitual.

Si el requisit és realment que no surti res del túnel, atureu el túnel en lloc d'això. L'espai de noms existeix per al cas mixt: un programa fora, tota la resta dins, a la mateixa màquina, al mateix temps.

Construeix el segon context i uneix-lo a l'amfitrió

Un disseny il·lustratiu: l'amfitrió té una interfície WireGuard que porta la ruta per defecte, i un espai de noms de xarxa anomenat clearnet connectat a l'amfitrió mitjançant un parell veth. Les adreces de sota són exemples.

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

Aquest espai de noms ara pot arribar a l'amfitrió i a res més. L'amfitrió ha de reenviar el trànsit i reescriure l'adreça d'origen, perquè 192.168.100.0/24 és privada i el router superior no té cap ruta de tornada cap a ella:

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

Confirmeu el costat de l'espai de noms abans de continuar.ip netns exec clearnet ip route hauria de mostrar la ruta veth i la ruta per defecte a través de 192.168.100.1, i un ping a aquesta adreça hauria de respondre. Si el ping a l'adreça de l'amfitrió falla, les adreces o l'estat de l'enllaç són incorrectes i cap regla de tallafocs ajudarà.

Quan els noms es resolen però no torna res, llegiu FORWARD

La fallada clàssica sembla un error d'encaminament: l'espai de noms resol un nom, el paquet surt i no arriba mai cap resposta. Als amfitrions amb una política FORWARD de DROP — així ho fan diverses distribucions i la majoria d'imatges endurides — el paquet es descarta de camí, i l'error que imprimeix l'aplicació no diu res sobre el filtratge.

Llegiu la cadena abans d'afegir res:

iptables -S FORWARD
nft list chain inet filter forward

A continuació admeteu el trànsit en totes dues direccions, amb comptadors, perquè pugueu veure si la regla ha coincidit mai:

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 amb un comptador de paquets a zero no és al camí. O els noms de les interfícies difereixen del que heu suposat, o una regla anterior de la cadena ha acceptat, descartat o retornat el paquet primer. Arregleu l'ordre, no el text de la regla.

El trànsit de resposta és la meitat que la gent oblida. La regla de retorn necessita el mateix nom veth més una coincidència d'estat de connexió, o una acceptació d'interfície simple si manteniu la política oberta. Afegiu només la regla de sortida i el símptoma original torna, amb la vostra regla nova allà i aparentment correcta.

Manteniu les regles de marcatge del túnel fora del camí nou

Aquest pas converteix un espai de noms que funciona en un que té fuites. Les configuracions de WireGuard solen instal·lar una política de marca de tallafocs més les seves pròpies regles d'encaminament i una taula dedicada, de manera que els paquets sense marca tornen a la taula principal mentre els marcats fan servir la taula del túnel. El trànsit reenviat des de l'espai de noms s'avalua contra l'encaminament per política a la sortida i, segons com s'hagin escrit aquestes regles, pot caure a la taula del túnel.

Dos afegits separen els camins. Torneu aviat a la cadena mangle per a la subxarxa de l'espai de noms i afegiu una regla basada en l'origen que posa aquesta subxarxa a la taula 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 prioritat 100 s'ordena abans de les regles del túnel al meu amfitrió, així que per a aquest origen decideix la taula normal. No copieu el número cegament: les prioritats que wg-quick instal·la difereixen entre versions i entre les configuracions IPv4 i IPv6, així que executeu ip rule show i trieu una prioritat que quedi davant de les regles del túnel a la vostra màquina.

Verifiqueu amb una consulta específica per origen en lloc de confiar en la llista de regles:

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

Si la primera ordre informa de la interfície WireGuard, la regla nova encara no és davant de la política del túnel. Si informa de la interfície WAN mentre la segona encara mostra la ruta per defecte veth, l'amfitrió i l'espai de noms no coincideixen i hauríeu de rellegir les dues taules d'encaminament.

Inicieu el procés que obre la connexió

Iniciar l'ordre és una línia, però inicieu el procés que realment crea el sòcol.ip netns exec clearnet curl -s https://ifconfig.me és la prova honesta més petita: mostra l'adreça que l'espai de noms presenta al món, no la que faria servir l'amfitrió.

Per a un servei, adjunteu l'espai de noms per camí perquè el procés hi romangui tota la seva vida:

[Service]
NetworkNamespacePath=/run/netns/clearnet

Les aplicacions gràfiques són on l'enfocament d'una línia falla silenciosament. Un navegador iniciat des d'un menú sovint lliura la petició a una instància que ja s'executa fora de l'espai de noms, així que la finestra nova apareix i el trànsit continua sortint pel túnel. Doneu-li un perfil separat perquè es creï realment una instància nova, i després mireu el context del procés en lloc d'endevinar:

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

Les dues sortides han de coincidir. La mateixa comprovació funciona per a qualsevol programa de llarga durada, i val la pena fer-la una vegada per aplicació en lloc de suposar que el llançador ha fet el que volíeu.

La resolució de noms necessita la seva pròpia decisió. Crear un espai de noms no li dona configuració de resolució; els fitxers per espai de noms s'admeten mitjançant /etc/netns/<name>/resolv.conf i sense cap hereteu un comportament que és fàcil de llegir malament. IPv6 necessita el mateix tracte: si l'espai de noms no té ruta per defecte v6 mentre l'aplicació prefereix v6, les peticions es poden encallar abans de retrocedir, cosa que sembla un túnel trencat.

Comproveu l'emmarcament, no només l'adreça de sortida

Una adreça pública que funciona demostra la ruta, no tot el requisit. Recorreu la resta en aquest ordre:

• ip netns exec clearnet ip route get 1.1.1.1 mostra la ruta per defecte veth, no la interfície WireGuard.
• Els comptadors FORWARD de les dues regles augmenten mentre s'executa una petició.
• El procés de l'aplicació informa de l'inode de l'espai de noms que espereu.
• Després d'un reinici l'espai de noms existeix abans que arrenqui el servei; una unitat que s'executi abans falla o, pitjor, s'executa fora de l'espai de noms.

Després decidiu què ha de passar quan el túnel caigui. L'espai de noms continua funcionant, que és el punt de l'exercici i també el risc: el programa eximit continua connectat mentre la resta s'atura. Enregistreu-ho com una decisió de política i sigueu clars sobre què no cobreix l'exempció — la identitat del compte, l'estat desat del navegador i el vostre proveïdor de DNS queden tots fora de l'abast d'un espai de noms de xarxa, i tractar l'exempció com a anonimat és l'error que sobreviu a la configuració.