Sådan kører du én Linux-proces uden for en WireGuard-tunnel

Du kan ikke fritage et program fra en WireGuard-vært med fuld tunnel ved at redigere ruter. Ruter vælger en vej efter destination, og det, du vil fritage, er en proces, så kernen har intet at matche på. Den brugbare tilgang er at give den proces sin egen netværkskontekst: et navnerum med sit eget interface, sine egne adresser og sin egen standardrute, forbundet med værten via et veth-par. Jeg kørte det på Ubuntu 24.04 med wireguard-tools 1.0.20210914, og navnerummet var aldrig problemet — værtens videresendelsespolitik og tunnelens mærkningsregler var.

Vælg først den slags kontekst, du har brug for

I praksis optræder to former. Hvis værten kører en fuld tunnel, og ét program skal forlade den ad ISP-stien, bygger du et andet navnerum, forbinder det med værten og lader værten videresende og oversætte trafikken for det. Hvis et navnerum allerede har et VPN-interface, og du kun har brug for en kommando startet inde i det, er det det almindelige ip netns exec tilfælde, og det meste af rutearbejdet er allerede gjort.

Ingen af formerne giver dig en regel, der er afgrænset til ét proces-id. Netfilter matcher adresser, porte, mærker og interfaces; der findes ingen rutetabel per proces. Mærkning kan styre trafikken, men mærket skal sættes på pakker, du allerede har identificeret, og det er det samme problem et lag længere nede. Et navnerum adskiller hele stakken for det procestræ, og derfor er det det sædvanlige svar.

Hvis kravet reelt er, at intet forlader tunnelen, så stop tunnelen i stedet. Navnerummet findes til det blandede tilfælde: ét program ud, alt andet ind, på samme maskine, på samme tid.

Byg den anden kontekst og forbind den med værten

Et illustrativt layout: værten har et WireGuard-interface, der bærer standardruten, og et netværksnavnerum kaldet clearnet forbundet med værten via et veth-par. Adresserne nedenfor er eksempler.

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

Det navnerum kan nu nå værten og intet andet. Værten skal videresende trafikken og omskrive kildeadressen, fordi 192.168.100.0/24 er privat, og den opstrøms router har ingen rute tilbage i den:

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

Bekræft navnerummets side, før du går videre.ip netns exec clearnet ip route skal vise veth-ruten og standardruten via 192.168.100.1, og et ping til den adresse skal svare. Hvis ping til værtens adresse fejler, er adresserne eller forbindelsestilstanden forkerte, og ingen firewallregel hjælper.

Når navne opløses, men intet kommer tilbage, så læs FORWARD

Den klassiske fejl ser ud som en rutebug: navnerummet opløser et navn, pakken forlader maskinen, og der kommer aldrig et svar. På værter med en FORWARD-politik på DROP — det gør flere distributioner og de fleste hærdede images — droppes pakken undervejs, og den fejl, programmet udskriver, siger intet om filtrering.

Læs kæden, før du tilføjer noget:

iptables -S FORWARD
nft list chain inet filter forward

Slip derefter trafikken igennem i begge retninger, med tællere, så du kan se, om reglen nogensinde har matchet:

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'

En regel med en pakketæller på nul er ikke i stien. Enten afviger interfacenavnene fra det, du antog, eller også har en tidligere regel i kæden accepteret, droppet eller returneret pakken først. Ret rækkefølgen, ikke reglens tekst.

Svartrafik er den halvdel, folk glemmer. Returreglen skal bruge det samme veth-navn plus et match på forbindelsestilstand, eller en almindelig interface-accept, hvis du holder politikken åben. Tilføj kun den udgående regel, og det oprindelige symptom er tilbage, mens din nye regel står der og ser korrekt ud.

Hold tunnelens mærkningsregler væk fra den nye sti

Dette trin gør et fungerende navnerum til et lækkende et. WireGuard-opsætninger installerer typisk en firewall-mærkepolitik plus deres egne ruterregler og en dedikeret tabel, så umærkede pakker falder tilbage til hovedtabellen, mens mærkede pakker bruger tunneltabellen. Videresendt trafik fra navnerummet vurderes mod policy routing på vej ud, og afhængigt af hvordan de regler er skrevet, kan den ende i tunneltabellen.

To tilføjelser adskiller stierne. Returner tidligt i mangle-kæden for navnerummets undernet, og tilføj en kildebaseret regel, der lægger det undernet i hovedtabellen:

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

Prioritet 100 sorteres foran tunnelreglerne på min vært, så den almindelige tabel afgør for den kilde. Kopiér ikke tallet blindt: de prioriteter, som wg-quick installerer, varierer mellem versioner og mellem IPv4- og IPv6-opsætningerne, så kør ip rule show og vælg en prioritet, der ligger foran tunnelreglerne på din maskine.

Bekræft med et kildespecifikt opslag i stedet for at stole på regellisten:

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

Hvis den første kommando rapporterer WireGuard-interfacet, er den nye regel ikke foran tunnelpolitikken endnu. Hvis den rapporterer WAN-interfacet, mens den anden stadig viser veth-standardruten, er værten og navnerummet uenige, og du bør læse begge rutetabeller igen.

Start den proces, der åbner forbindelsen

At starte kommandoen er én linje, men start den proces, der faktisk opretter socket'en.ip netns exec clearnet curl -s https://ifconfig.me er den mindste ærlige test: den viser den adresse, navnerummet præsenterer for omverdenen, ikke den, værten ville bruge.

Ved en tjeneste skal du knytte navnerummet via sti, så processen bliver i det hele sit liv:

[Service]
NetworkNamespacePath=/run/netns/clearnet

Grafiske programmer er dér, hvor énlinjetilgangen stille fejler. En browser startet fra en menu giver ofte anmodningen til en instans, der allerede kører uden for navnerummet, så det nye vindue dukker op, og trafikken forlader stadig via tunnelen. Giv den en separat profil, så en ny instans virkelig oprettes, og tjek derefter processens kontekst i stedet for at gætte:

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

De to output skal stemme overens. Den samme kontrol virker for ethvert langvarigt program, og det er værd at gøre det én gang per program i stedet for at antage, at starteren gjorde, hvad du mente.

Navneopløsning kræver sin egen beslutning. Oprettelse af et navnerum giver det ikke en resolver-konfiguration; filer per navnerum understøttes via /etc/netns/<name>/resolv.conf og uden en arver du adfærd, der er let at læse forkert. IPv6 kræver samme behandling: hvis navnerummet ikke har en v6-standardrute, mens programmet foretrækker v6, kan anmodninger hænge, før de falder tilbage, hvilket ligner en brudt tunnel.

Tjek indramningen, ikke kun udgangsadressen

En fungerende offentlig adresse beviser ruten, ikke hele kravet. Gå gennem resten i denne rækkefølge:

• ip netns exec clearnet ip route get 1.1.1.1 viser veth-standardruten, ikke WireGuard-interfacet.
• FORWARD-tællerne på begge regler stiger, mens en anmodning kører.
• Programmets proces rapporterer det navnerums-inode, du forventer.
• Efter en genstart findes navnerummet, før tjenesten starter; en unit, der kører tidligere, fejler eller, værre, kører uden for navnerummet.

Beslut derefter, hvad der skal ske, når tunnelen falder. Navnerummet bliver ved med at virke, og det er pointen med øvelsen og også risikoen: det fritagne program forbliver forbundet, mens alt andet stopper. Skriv det ned som et politikvalg, og vær klar over, hvad fritagelsen ikke dækker — kontoidentitet, gemt browsertilstand og din DNS-udbyder står alle uden for rammerne af et netværksnavnerum, og at behandle fritagelsen som anonymitet er den fejl, der overlever konfigurationen.