Hoe om een Linux-proses buite 'n WireGuard-tonnel te laat werk

Jy kan nie 'n program van 'n WireGuard-gasheer met 'n volledige tonnel vrystel deur die roetes te wysig nie. Roetes kies 'n pad volgens bestemming, en wat jy wil vrystel is 'n proses, so die kernel het niks om op te pas nie. Die werkbare benadering is om daardie proses sy eie netwerkkonteks te gee: 'n naamruimte met sy eie koppelvlak, adresse en verstekroete, wat deur 'n veth-paar aan die gasheer gekoppel is. Ek het dit op Ubuntu 24.04 met wireguard-tools 1.0.20210914 uitgevoer, en die naamruimte was nooit die probleem nie — die gasheer se deurvoerbeleid en die tonnel se merkingsreëls was.

Kies eers die soort konteks wat jy nodig het

Twee vorms kom in die praktyk voor. As die gasheer 'n volledige tonnel het en een program moet via die ISP-pad uitgaan, bou jy 'n tweede naamruimte, koppel dit aan die gasheer en laat die gasheer die verkeer vir dit deurstuur en vertaal. As 'n naamruimte reeds 'n VPN-koppelvlak het en jy net 'n opdrag daarbinne wil begin, is dit die gewone ip netns exec geval, en die meeste van die roetewerk is reeds gedoen.

Geen van die twee vorms gee jou 'n reël wat aan 'n enkele proses-ID gekoppel is nie. Netfilter pas adresse, poorte, merke en koppelvlakke; daar is geen roetetabel per proses nie. Merk kan verkeer stuur, maar die merk moet op pakkette toegepas word wat jy reeds geïdentifiseer het, wat dieselfde probleem een laag laer is. 'n Naamruimte skei die hele stapel vir daardie prosesboom, en daarom is dit die gewone antwoord.

As die vereiste werklik is dat niks die tonnel verlaat nie, stop eerder die tonnel. Die naamruimte bestaan vir die gemengde geval: een program uit, alles anders in, op dieselfde masjien, op dieselfde tyd.

Bou die tweede konteks en koppel dit aan die gasheer

'n Illustratiewe uitleg: die gasheer het 'n WireGuard-koppelvlak wat die verstekroete dra, en 'n netwerknaamruimte genaamd clearnet wat deur 'n veth-paar aan die gasheer gekoppel is. Die adresse hieronder is voorbeelde.

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

Daardie naamruimte kan nou die gasheer bereik en niks anders nie. Die gasheer moet die verkeer deurstuur en die bronadres herskryf, want 192.168.100.0/24 is privaat en die opstroomroeteerder het geen roete terug daarin nie:

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

Bevestig die naamruimte se kant voordat jy verder gaan.ip netns exec clearnet ip route moet die veth-roete en die verstekroete via 192.168.100.1 wys, en 'n ping na daardie adres moet antwoord. As ping na die gasheer se adres misluk, is die adresse of die skakeltoestand verkeerd en geen firewall-reël sal help nie.

Wanneer name oplos maar niks terugkom, lees FORWARD

Die klassieke faling lyk soos 'n roetefout: die naamruimte los 'n naam op, die pakket verlaat die masjien, en geen antwoord kom ooit aan nie. Op gashere wat 'n FORWARD-beleid van DROP het — verskeie verspreidings en die meeste geharde beelde het dit — word die pakket op pad deur laat val, en die fout wat die toepassing druk, sê niks oor filtering nie.

Lees die ketting voordat jy iets byvoeg:

iptables -S FORWARD
nft list chain inet filter forward

Laat die verkeer dan in beide rigtings toe, met tellers, sodat jy kan sien of die reël ooit gepas het:

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'

'n Reël met 'n nul-pakketteller is nie in die pad nie. Óf die koppelvlakname verskil van wat jy aangeneem het, óf 'n vroeëre reël in die ketting het die pakket eerste aanvaar, laat val of teruggegee. Maak die volgorde reg, nie die reëlteks nie.

Antwoordverkeer is die helfte wat mense vergeet. Die terugkeerreël het dieselfde veth-naam nodig plus 'n verbindingstoestand-pas, of 'n gewone koppelvlak-aanvaarding as jy die beleid oop hou. Voeg net die uitgaande reël by en jy kry die oorspronklike simptoom terug, met jou nuwe reël wat daar korrek lyk.

Hou die tonnel se merkingsreëls weg van die nuwe pad

Hierdie stap verander 'n werkende naamruimte in een wat lek. WireGuard-opstellings installeer gewoonlik 'n firewall-merkbeleid plus hul eie roetereëls en 'n toegewyde tabel, sodat ongemerkte pakkette na die hoof-tabel terugval terwyl gemerkte pakkette die tonneltabel gebruik. Deurgevoerde verkeer uit die naamruimte word op pad uit teen beleidsroetering geëvalueer, en afhangend van hoe daardie reëls geskryf is, kan dit in die tonneltabel beland.

Twee byvoegings skei die paaie. Keer vroeg terug in die mangle-ketting vir die naamruimte-subnet, en voeg 'n bron-gebaseerde reël by wat daardie subnet in die hoof-tabel plaas:

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

Prioriteit 100 sorteer voor die tonnelreëls op my gasheer, so die gewone tabel besluit vir daardie bron. Moenie die nommer blindelings kopieer nie: die prioriteite wat wg-quick installeer, verskil tussen weergawes en tussen die IPv4- en IPv6-opstellings, so voer ip rule show uit en kies 'n prioriteit wat voor die tonnelreëls op jou masjien val.

Verifieer met 'n bronspesifieke soektog eerder as om die reëllijst te vertrou:

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

As die eerste opdrag die WireGuard-koppelvlak rapporteer, is die nuwe reël nog nie voor die tonnelbeleid nie. As dit die WAN-koppelvlak rapporteer terwyl die tweede steeds die veth-verstek wys, stem die gasheer en die naamruimte nie ooreen nie en moet jy albei roetetabelle weer lees.

Begin die proses wat die verbinding oopmaak

Om die opdrag te begin is een lyn, maar begin die proses wat werklik die sokket skep.ip netns exec clearnet curl -s https://ifconfig.me is die kleinste eerlike toets: dit wys die adres wat die naamruimte aan die wêreld voorhou, nie die een wat die gasheer sou gebruik nie.

Vir 'n diens, koppel die naamruimte volgens pad sodat die proses sy hele lewe daarin bly:

[Service]
NetworkNamespacePath=/run/netns/clearnet

Grafiese toepassings is waar die een-lyn-benadering stilweg misluk. 'n Blaaier wat uit 'n kieslys begin word, gee die versoek dikwels aan 'n instansie wat reeds buite die naamruimte loop, so die nuwe venster verskyn en die verkeer verlaat steeds via die tonnel. Gee dit 'n aparte profiel sodat 'n nuwe instansie werklik geskep word, en kyk dan na die proseskonteks in plaas daarvan om te raai:

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

Die twee uitsette moet ooreenstem. Dieselfde toets werk vir enige langdurige program, en dit is die moeite werd om dit een keer per toepassing te doen eerder as om te aanvaar dat die laeër gedoen het wat jy bedoel het.

Naamresolusie het sy eie besluit nodig. Die skep van 'n naamruimte gee dit nie 'n resolver-konfigurasie nie; per-naamruimte lêers word ondersteun deur /etc/netns/<name>/resolv.conf en sonder een erf jy gedrag wat maklik verkeerd gelees word. IPv6 het dieselfde behandeling nodig: as die naamruimte geen v6-verstekroete het terwyl die toepassing v6 verkies, kan versoeke vasval voordat hulle terugval, wat soos 'n gebreekte tonnel lyk.

Kontroleer die raamwerk, nie net die uitgangsadres nie

'n Werkende publieke adres bewys die roete, nie die hele vereiste nie. Stap deur die res in hierdie volgorde:

• ip netns exec clearnet ip route get 1.1.1.1 wys die veth-verstek, nie die WireGuard-koppelvlak nie.
• Die FORWARD-tellers op albei reëls verhoog terwyl 'n versoek loop.
• Die toepassingsproses rapporteer die naamruimte-inode wat jy verwag.
• Na 'n herbegin bestaan die naamruimte voordat die diens begin; 'n eenheid wat vroeër loop, misluk, of erger, loop buite die naamruimte.

Besluit dan wat moet gebeur wanneer die tonnel val. Die naamruimte bly werk, wat die punt van die oefening is en ook die risiko: die vrygestelde program bly verbind terwyl alles anders stop. Teken dit as 'n beleidskeuse aan, en wees duidelik oor wat die vrystelling nie dek nie — rekeningidentiteit, gestoorde blaaierstate en jou DNS-verskaffer sit almal buite die bestek van 'n netwerknaamruimte, en om die vrystelling as anonimiteit te behandel is die fout wat die konfigurasie oorleef.