Hvordan kjøre én Linux-prosess utenfor en WireGuard-tunnel

Du kan ikke unnta et program fra en WireGuard-vert med full tunnel ved å redigere ruter. Ruter velger en vei etter destinasjon, og det du vil unnta er en prosess, så kjernen har ingenting å matche på. Den gangbare tilnærmingen er å gi den prosessen sin egen nettverkskontekst: et navnerom med sitt eget grensesnitt, egne adresser og egen standardrute, koblet til verten med et veth-par. Jeg kjørte dette på Ubuntu 24.04 med wireguard-tools 1.0.20210914, og navnerommet var aldri problemet — vertens videresendingspolicy og tunnelens merkeregler var det.

Velg først hva slags kontekst du trenger

I praksis dukker det opp to former. Hvis verten kjører en full tunnel og ett program skal ut via ISP-veien, bygger du et andre navnerom, kobler det til verten og lar verten videresende og oversette trafikken for det. Hvis et navnerom allerede bærer et VPN-grensesnitt og du bare trenger en kommando startet inne i det, er det det vanlige ip netns exec-tilfellet, og det meste av rutejobben er allerede gjort.

Ingen av formene gir deg en regel begrenset til én prosess-ID. Netfilter matcher adresser, porter, merker og grensesnitt; det finnes ingen rutetabell per prosess. Merking kan styre trafikk, men merket må settes på pakker du allerede har identifisert, og det er det samme problemet ett lag lenger ned. Et navnerom skiller hele stakken for det prosesstreet, og derfor er det det vanlige svaret.

Hvis kravet virkelig er at ingenting forlater tunnelen, stopp tunnelen i stedet. Navnerommet finnes for det blandede tilfellet: ett program ut, alt annet inn, på samme maskin, samtidig.

Bygg den andre konteksten og koble den til verten

Et illustrerende oppsett: verten har et WireGuard-grensesnitt som bærer standardruten, og et nettverksnavnerom kalt clearnet koblet til verten med et veth-par. Adressene 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 navnerommet kan nå nå verten og ingenting annet. Verten må videresende trafikken og skrive om kildeadressen, fordi 192.168.100.0/24 er privat og ruteren ovenfor ikke har noen rute tilbake inn i det:

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

Bekreft navneromssiden før du går videre.ip netns exec clearnet ip route skal vise veth-ruten og standardruten via 192.168.100.1, og en ping til den adressen skal svare. Hvis ping til vertens adresse feiler, er adressene eller lenketilstanden feil, og ingen brannmurregel hjelper.

Når navn løses men ingenting kommer tilbake, les FORWARD

Den klassiske feilen ser ut som en rutefeil: navnerommet løser et navn, pakken går ut, og det kommer aldri et svar. På verter med FORWARD-policy DROP — det gjør flere distribusjoner og de fleste herdede images — blir pakken droppet underveis, og feilen programmet skriver ut sier ingenting om filtrering.

Les kjeden før du legger til noe:

iptables -S FORWARD
nft list chain inet filter forward

Slipp deretter trafikken gjennom i begge retninger, med tellere, så du kan se om regelen noen gang 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 null pakketeller er ikke i veien. Enten avviker grensesnittnavnene fra det du antok, eller en tidligere regel i kjeden godtok, droppet eller returnerte pakken først. Rett rekkefølgen, ikke regelteksten.

Svartrafikk er den halvdelen folk glemmer. Returregelen trenger samme veth-navn pluss en match på tilkoblingstilstand, eller en vanlig grensesnittgodkjenning hvis du holder policyen åpen. Legg bare til den utgående regelen, og det opprinnelige symptomet er tilbake, mens den nye regelen står der og ser riktig ut.

Hold tunnelens merkeregler unna den nye veien

Dette trinnet gjør et fungerende navnerom til et lekkende et. WireGuard-oppsett installerer vanligvis en brannmurmerkepolicy sammen med egne rutingregler og en egen tabell, slik at umerkede pakker faller tilbake til hovedtabellen mens merkede pakker bruker tunneltabellen. Videresendt trafikk fra navnerommet vurderes mot policy-ruting på vei ut, og avhengig av hvordan disse reglene er skrevet, kan den havne i tunneltabellen.

To tillegg skiller veiene. Returner tidlig i mangle-kjeden for navnerommets subnett, og legg til en kildebasert regel som setter det subnettet 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 tunnelreglene på verten min, så den vanlige tabellen avgjør for den kilden. Ikke kopier tallet blindt: prioritetene som wg-quick installerer, varierer mellom versjoner og mellom IPv4- og IPv6-oppsettene, så kjør ip rule show og velg en prioritet som ligger foran tunnelreglene på maskinen din.

Verifiser med et kildespesifikt oppslag i stedet for å 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 kommandoen rapporterer WireGuard-grensesnittet, er den nye regelen ennå ikke foran tunnelpolicyen. Hvis den rapporterer WAN-grensesnittet mens den andre fortsatt viser veth-standardruten, er verten og navnerommet uenige, og du bør lese begge rutetabellene på nytt.

Start prosessen som åpner tilkoblingen

Å starte kommandoen er én linje, men start prosessen som faktisk lager socketen.ip netns exec clearnet curl -s https://ifconfig.me er den minste ærlige testen: den viser adressen navnerommet presenterer for verden, ikke den verten ville brukt.

For en tjeneste, fest navnerommet via sti slik at prosessen blir i det hele livet:

[Service]
NetworkNamespacePath=/run/netns/clearnet

Grafiske programmer er der éenlinjetilnærmingen stille feiler. En nettleser startet fra en meny gir ofte forespørselen til en instans som allerede kjører utenfor navnerommet, så det nye vinduet dukker opp og trafikken går fortsatt ut via tunnelen. Gi den en egen profil slik at en ny instans virkelig opprettes, og sjekk deretter prosesskonteksten i stedet for å gjette:

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

De to utdataene må stemme overens. Den samme sjekken fungerer for ethvert langvarig program, og det er verdt å gjøre den én gang per program i stedet for å anta at startprogrammet gjorde det du mente.

Navneoppslag trenger sin egen avgjørelse. Å opprette et navnerom gir det ikke en resolver-konfigurasjon; filer per navnerom støttes via /etc/netns/<name>/resolv.conf og uten en arver du oppførsel som er lett å lese feil. IPv6 trenger samme behandling: hvis navnerommet ikke har en v6-standardrute mens programmet foretrekker v6, kan forespørsler henge før de faller tilbake, noe som ser ut som en ødelagt tunnel.

Sjekk innrammingen, ikke bare utgangsadressen

En fungerende offentlig adresse beviser ruten, ikke hele kravet. Gå gjennom resten i denne rekkefølgen:

• ip netns exec clearnet ip route get 1.1.1.1 viser veth-standardruten, ikke WireGuard-grensesnittet.
• FORWARD-tellerne på begge reglene øker mens en forespørsel kjører.
• Programprosessen rapporterer navnerom-inoden du forventer.
• Etter en omstart finnes navnerommet før tjenesten starter; en unit som kjører tidligere, feiler eller, verre, kjører utenfor navnerommet.

Avgjøre deretter hva som skal skje når tunnelen faller. Navnerommet fortsetter å virke, og det er poenget med øvelsen og også risikoen: det unntatte programmet forblir tilkoblet mens alt annet stopper. Skriv det ned som et policyvalg, og vær tydelig på hva unntaket ikke dekker — kontoidentitet, lagret nettlesertilstand og DNS-leverandøren din ligger alle utenfor rekkevidden til et nettverksnavnerom, og å behandle unntaket som anonymitet er feilen som overlever konfigurasjonen.