Como executar un proceso de Linux fóra dun túnel de WireGuard

Non pode eximir un programa dun equipo WireGuard con túnel completo editando rutas. As rutas escollen un camiño por destino, e o que quere eximir é un proceso, así que o núcleo non ten con que emparellalo. O enfoque viable é darlle a ese proceso o seu propio contexto de rede: un espazo de nomes coa súa propia interface, os seus enderezos e a súa ruta predeterminada, unido ao equipo mediante un par veth. Executeino en Ubuntu 24.04 con wireguard-tools 1.0.20210914, e o espazo de nomes nunca foi o problema: fórono a política de reenvío do equipo e as regras de marcado do túnel.

Primeiro escolla o tipo de contexto que necesita

Na práctica aparecen dúas formas. Se o equipo executa un túnel completo e un programa debe saír pola ruta do ISP, constrúe un segundo espazo de nomes, conéctao ao equipo e deixa que o equipo reenvíe e traduza o tráfico por el. Se un espazo de nomes xa leva unha interface VPN e só necesita un comando iniciado dentro, ese é o caso simple de ip netns exec e a maior parte do traballo de enrutamento xa está feita.

Ningunha das dúas formas lle dá unha regra limitada a un só identificador de proceso. Netfilter empareja enderezos, portos, marcas e interfaces; non hai táboa de enrutamento por proceso. O marcado pode dirixir o tráfico, pero a marca debe aplicarse a paquetes que xa identificou, e ese é o mesmo problema unha capa máis abaixo. Un espazo de nomes separa toda a pila para esa árbore de procesos, e por iso é a resposta habitual.

Se o requisito é realmente que nada saia do túnel, deteña o túnel no seu lugar. O espazo de nomes existe para o caso mixto: un programa fóra, todo o demais dentro, na mesma máquina, ao mesmo tempo.

Constrúa o segundo contexto e únao ao equipo

Un deseño ilustrativo: o equipo ten unha interface WireGuard que leva a ruta predeterminada, e un espazo de nomes de rede chamado clearnet unido ao equipo mediante un par veth. Os enderezos de abaixo son exemplos.

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 espazo de nomes agora pode chegar ao equipo e a nada máis. O equipo debe reenviar o tráfico e reescribir o enderezo de orixe, porque 192.168.100.0/24 é privada e o router upstream non ten ruta de volta cara a ela:

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

Confirme o lado do espazo de nomes antes de seguir.ip netns exec clearnet ip route debería mostrar a ruta veth e a ruta predeterminada a través de 192.168.100.1, e un ping a ese enderezo debería responder. Se o ping ao enderezo do equipo falla, os enderezos ou o estado da ligazón están mal e ningunha regra de devasado axudará.

Cando os nomes se resolven pero non volve nada, lea FORWARD

O fallo clásico parece un erro de enrutamento: o espazo de nomes resolve un nome, o paquete sae e nunca chega unha resposta. Nos equipos cunha política FORWARD de DROP — así o fan varias distribucións e a maioría das imaxes endurecidas — o paquete descártase de camiño, e o erro que imprime a aplicación non di nada sobre o filtrado.

Lea a cadea antes de engadir nada:

iptables -S FORWARD
nft list chain inet filter forward

Logo admita o tráfico en ambas as direccións, con contadores, para que poida ver se a regra chegou 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'

Unha regra cun contador de paquetes a cero non está no camiño. Ou os nomes das interfaces difiren do que supuxo, ou unha regra anterior da cadea aceptou, descartou ou devolveu o paquete primeiro. Corrixa a orde, non o texto da regra.

O tráfico de resposta é a metade que a xente esquece. A regra de retorno necesita o mesmo nome veth máis unha coincidencia de estado de conexión, ou unha aceptación de interface simple se mantén a política aberta. Engada só a regra de saída e o síntoma orixinal volve, coa súa regra nova alí e aparentemente correcta.

Manteña as regras de marcado do túnel fóra do camiño novo

Este paso converte un espazo de nomes que funciona nun que filtra. As configuracións de WireGuard adoitan instalar unha política de marca de devasado xunto coas súas propias regras de enrutamento e unha táboa dedicada, de xeito que os paquetes sen marca volven á táboa principal mentres os marcados usan a táboa do túnel. O tráfico reenviado desde o espazo de nomes avalíase contra o enrutamento por políticas á saída e, segundo como se escribiron esas regras, pode caer na táboa do túnel.

Dous engadidos separan os camiños. Volva cedo na cadea mangle para a subrede do espazo de nomes e engada unha regra baseada na orixe que pon esa subrede na táboa 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

A prioridade 100 ordease antes das regras do túnel no meu equipo, así que para esa orixe decide a táboa normal. Non copie o número a cegas: as prioridades que wg-quick instala difiren entre versións e entre as configuracións de IPv4 e IPv6, así que execute ip rule show e escolla unha prioridade que quede diante das regras do túnel na súa máquina.

Verifique con unha busca específica de orixe en lugar de confiar na lista de regras:

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

Se o primeiro comando informa da interface WireGuard, a regra nova aínda non está diante da política do túnel. Se informa da interface WAN mentres o segundo segue mostrando a ruta predeterminada veth, o equipo e o espazo de nomes non coinciden e debería reler ambas as táboas de enrutamento.

Inicie o proceso que abre a conexión

Iniciar o comando é unha liña, pero inicie o proceso que crea realmente o socket.ip netns exec clearnet curl -s https://ifconfig.me é a proba honesta máis pequena: mostra o enderezo que o espazo de nomes presenta ao mundo, non o que usaría o equipo.

Para un servizo, adjunte o espazo de nomes por ruta para que o proceso permaneza nel toda a súa vida:

[Service]
NetworkNamespacePath=/run/netns/clearnet

As aplicacións gráficas son onde o enfoque dunha liña falla en silencio. Un navegador iniciado desde un menú adoita entregar a solicitude a unha instancia que xa se executa fóra do espazo de nomes, así que aparece a ventá nova e o tráfico segue saíndo polo túnel. Déalle un perfil separado para que se cree realmente unha instancia nova e despois comprobe o contexto do proceso en lugar de adiviñar:

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

As dúas saídas deben coincidir. A mesma comprobación serve para calquera programa de longa duración, e paga a pena facela unha vez por aplicación en lugar de supor que o lanzador fixo o que vostede quería.

A resolución de nomes necesita a súa propia decisión. Crear un espazo de nomes non lle dá configuración de resolución; os ficheiros por espazo de nomes admítense mediante /etc/netns/<name>/resolv.conf e sen un herda un comportamento que é fácil de ler mal. IPv6 necesita o mesmo trato: se o espazo de nomes non ten ruta predeterminada v6 mentres a aplicación prefire v6, as solicitudes poden atascarse antes de retroceder, o que parece un túnel roto.

Comprobe o encadramento, non só o enderezo de saída

Un enderezo público que funciona demostra a ruta, non todo o requisito. Percorra o resto nesta orde:

• ip netns exec clearnet ip route get 1.1.1.1 mostra a ruta predeterminada veth, non a interface WireGuard.
• Os contadores FORWARD de ambas as regras aumentan mentres se executa unha solicitude.
• O proceso da aplicación informa do inodo do espazo de nomes que espera.
• Tras un reinicio o espazo de nomes existe antes de que arrinque o servizo; unha unidade que se execute antes falla ou, peor, execútase fóra do espazo de nomes.

Despois decida que debe ocorrer cando o túnel caia. O espazo de nomes segue funcionando, que é o obxectivo do exercicio e tamén o risco: o programa eximido segue conectado mentres todo o demais se detén. Anóteo como unha decisión de política e sexa claro sobre o que a exención non cobre: a identidade da conta, o estado gardado do navegador e o seu provedor de DNS quedan todos fóra do alcance dun espazo de nomes de rede, e tratar a exención como anonimato é o erro que sobrevive á configuración.