Korleis køyre éin Linux-prosess utanfor ein WireGuard-tunnel

Du kan ikkje unnta eit program frå ein WireGuard-vert med full tunnel ved å redigere ruter. Ruter vel ein veg etter destinasjon, og det du vil unnta er ein prosess, så kjernen har ingenting å matche på. Den gangbare tilnærminga er å gje den prosessen sin eigen nettverkskontekst: eit namnerom med sitt eige grensesnitt, eigne adresser og eigen standardrute, knytt til verten med eit veth-par. Eg køyrde dette på Ubuntu 24.04 med wireguard-tools 1.0.20210914, og namnerommet var aldri problemet — verten sin videresendingspolicy og tunnelens merkereglar var det.

Vel først kva slags kontekst du treng

I praksis dukkar det opp to former. Viss verten køyrer ein full tunnel og eitt program skal ut via ISP-vegen, byggjer du eit andre namnerom, knyter det til verten og lèt verten videresende og omsetje trafikken for det. Viss eit namnerom alt ber eit VPN-grensesnitt og du berre treng ein kommando starta inne i det, er det det vanlege ip netns exec-tilfellet, og det meste av rutejobben er alt gjort.

Ingen av formene gir deg ein regel avgrensa til éin prosess-ID. Netfilter matchar adresser, portar, merke og grensesnitt; det finst ingen rutetabell per prosess. Merking kan styre trafikk, men merket må setjast på pakkar du alt har identifisert, og det er det same problemet eitt lag lenger nede. Eit namnerom skil heile stakken for det prosesstreet, og difor er det det vanlege svaret.

Viss kravet verkeleg er at ingenting forlèt tunnelen, stopp tunnelen i staden. Namnerommet finst for det blanda tilfellet: eitt program ut, alt anna inn, på same maskin, samstundes.

Bygg den andre konteksten og knyt han til verten

Eit illustrerande oppsett: verten har eit WireGuard-grensesnitt som ber standardruta, og eit nettverksnamnerom kalla clearnet knytt til verten med eit veth-par. Adressene nedanfor er døme.

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 namnerommet kan no nå verten og ingenting anna. Verten må videresende trafikken og skrive om kjeldeadressa, fordi 192.168.100.0/24 er privat og rutaren ovanfor ikkje har noka rute tilbake inn i det:

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

Stadfest namneromssida før du går vidare.ip netns exec clearnet ip route skal vise veth-ruta og standardruta via 192.168.100.1, og ein ping til den adressa skal svare. Viss ping til adressa til verten feilar, er adressene eller lenkjetilstanden feil, og ingen brannmurregel hjelper.

Når namn blir løyste men ingenting kjem tilbake, les FORWARD

Den klassiske feilen ser ut som ein rutefeil: namnerommet løyser eit namn, pakken går ut, og det kjem aldri eit svar. På vertar med FORWARD-policy DROP — det gjer fleire distribusjonar og dei fleste herda images — blir pakken droppa undervegs, og feilen programmet skriv ut seier ingenting om filtrering.

Les kjeda før du legg til noko:

iptables -S FORWARD
nft list chain inet filter forward

Slepp deretter trafikken gjennom i begge retningar, med teljarar, så du kan sjå om regelen nokon gong har matcha:

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'

Ein regel med null pakketeljar er ikkje i vegen. Anten avvik grensesnittnamna frå det du antok, eller ein tidlegare regel i kjeda godtok, droppa eller returnerte pakken først. Rett rekkjefølgja, ikkje regelteksten.

Svartrafikk er den halvdelen folk gløymer. Returregelen treng same veth-namn pluss ein match på tilkoblingstilstand, eller ei vanleg grensesnittgodkjenning viss du held policyen open. Legg berre til den utgåande regelen, og det opphavlege symptomet er tilbake, medan den nye regelen står der og ser riktig ut.

Hald merkereglane til tunnelen unna den nye vegen

Dette trinnet gjer eit fungerande namnerom til eit lekkande eit. WireGuard-oppsett installerer vanlegvis ein brannmurmerkepolicy saman med eigne rutingsreglar og ein eigen tabell, slik at umerka pakkar fell tilbake til hovudtabellen medan merka pakkar brukar tunneltabellen. Videresend trafikk frå namnerommet blir vurdert mot policy-ruting på veg ut, og avhengig av korleis desse reglane er skrivne, kan han hamne i tunneltabellen.

To tillegg skil vegane. Kom tidleg tilbake i mangle-kjeda for subnettet til namnerommet, og legg til ein kjeldebasert regel som set det subnettet i hovudtabellen:

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 sorterer føre tunnelreglane på verten min, så den vanlege tabellen avgjer for den kjelda. Ikkje kopier talet blindt: prioriteringane som wg-quick installerer, varierer mellom versjonar og mellom IPv4- og IPv6-oppsetta, så køyr ip rule show og vel ein prioritet som ligg føre tunnelreglane på maskina di.

Stadfest med eit kjedespesifikt oppslag i staden for å stole på regellista:

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

Viss den første kommandoen rapporterer WireGuard-grensesnittet, er den nye regelen enno ikkje føre tunnelpolicyen. Viss han rapporterer WAN-grensesnittet medan den andre framleis viser veth-standardruta, er verten og namnerommet usamde, og du bør lese begge rutetabellane på nytt.

Start prosessen som opnar tilkoblinga

Å starte kommandoen er éi linje, men start prosessen som faktisk lagar socketen.ip netns exec clearnet curl -s https://ifconfig.me er den minste ærlege testen: han viser adressa namnerommet presenterer for verda, ikkje den verten ville brukt.

For ein teneste, fest namnerommet via stien slik at prosessen blir i det heile livet:

[Service]
NetworkNamespacePath=/run/netns/clearnet

Grafiske program er der éinlinjetilnærminga stille feilar. Ein nettlesar starta frå ei meny gir ofte førespurnaden til ein instans som alt køyrer utanfor namnerommet, så det nye vindauget dukkar opp og trafikken går framleis ut via tunnelen. Gje han ein eigen profil slik at ein ny instans verkeleg blir oppretta, og sjekk deretter prosesskonteksten i staden for å gjette:

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

Dei to utdata må stemme overeins. Den same sjekken fungerer for eitkvart langvarig program, og det er verdt å gjere han éin gong per program i staden for å anta at startprogrammet gjorde det du meinte.

Namneoppslag treng si eiga avgjerd. Å opprette eit namnerom gir det ikkje ein resolver-konfigurasjon; filer per namnerom blir støtta via /etc/netns/<name>/resolv.conf og utan ein arvar du åtferd som er lett å lese feil. IPv6 treng same behandling: viss namnerommet ikkje har ei v6-standardrute medan programmet føretrekk v6, kan førespurnader henge før dei fell tilbake, noko som ser ut som ein øydelagd tunnel.

Sjekk innramminga, ikkje berre utgangsadressa

Ei fungerande offentleg adresse provar ruta, ikkje heile kravet. Gå gjennom resten i denne rekkjefølgja:

• ip netns exec clearnet ip route get 1.1.1.1 viser veth-standardruta, ikkje WireGuard-grensesnittet.
• FORWARD-teljarane på begge reglane aukar medan ein førespurnad køyrer.
• Programprosessen rapporterer namnerom-inoden du forventar.
• Etter ein omstart finst namnerommet før tenesta startar; ein unit som køyrer tidlegare, feilar eller, verre, køyrer utanfor namnerommet.

Avgjer deretter kva som skal skje når tunnelen fell. Namnerommet held fram med å verke, og det er poenget med øvinga og òg risikoen: det unntatte programmet held fram med å vere tilkopla medan alt anna stoppar. Skriv det ned som eit policyval, og ver tydeleg på kva unntaket ikkje dekkjer — kontoidentitet, lagra nettlesartilstand og DNS-leverandøren din ligg alle utanfor rekkjevidda til eit nettverksnamnerom, og å behandle unntaket som anonymitet er feilen som overlever konfigurasjonen.