Kako pokrenuti jedan Linux proces izvan WireGuard tunela

Ne možete izuzeti program od WireGuard hosta s punim tunelom uređivanjem ruta. Rute biraju put po odredištu, a ono što želite izuzeti je proces, pa kernel nema s čime da upari. Izvediv pristup je dati tom procesu vlastiti mrežni kontekst: imenski prostor s vlastitim sučeljem, adresama i zadanom rutom, povezan s hostom pomoću veth para. Pokrenuo sam ovo na Ubuntu 24.04 s wireguard-tools 1.0.20210914 i imenski prostor nikada nije bio problem — problem su bili hostova politika prosljeđivanja i pravila označavanja tunela.

Prvo odaberite vrstu konteksta koja vam treba

U praksi se pojavljuju dva oblika. Ako host vodi puni tunel i jedan program treba izaći putem ISP-a, gradite drugi imenski prostor, povezujete ga s hostom i puštate host da za njega prosljeđuje i prevodi promet. Ako imenski prostor već nosi VPN sučelje i trebate samo naredbu pokrenutu unutar njega, to je običan ip netns exec slučaj i većina posla oko rutiranja je već obavljena.

Nijedan oblik vam ne daje pravilo ograničeno na jedan ID procesa. Netfilter uparuje adrese, portove, oznake i sučelja; ne postoji tablica rutiranja po procesu. Označavanje može usmjeriti promet, ali oznaka se mora staviti na pakete koje ste već prepoznali, a to je isti problem jedan sloj niže. Imenski prostor odvaja cijeli stog za to stablo procesa i zato je uobičajen odgovor.

Ako je zahtjev doista da ništa ne izlazi iz tunela, zaustavite tunel. Imenski prostor postoji za mješoviti slučaj: jedan program van, sve ostalo unutra, na istom stroju, u isto vrijeme.

Izgradite drugi kontekst i povežite ga s hostom

Ilustrativan raspored: host ima WireGuard sučelje koje nosi zadanu rutu i mrežni imenski prostor pod nazivom clearnet povezan s hostom pomoću veth para. Adrese ispod su primjeri.

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

Taj imenski prostor sada može doći do hosta i ničega drugog. Host mora prosljeđivati promet i prepisivati izvornu adresu, jer je 192.168.100.0/24 privatna i nadređeni usmjerivač nema rutu natrag u nju:

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

Potvrdite stranu imenskog prostora prije nego što nastavite.ip netns exec clearnet ip route treba pokazati veth rutu i zadanu rutu kroz 192.168.100.1, a ping na tu adresu treba odgovoriti. Ako ping na adresu hosta ne uspije, adrese ili stanje veze su pogrešni i nijedno pravilo vatrozida neće pomoći.

Kada se imena razrješavaju ali ništa ne dolazi natrag, čitajte FORWARD

Klasična greška izgleda kao bug u rutiranju: imenski prostor razriješi ime, paket izađe i odgovor nikada ne stigne. Na hostovima s FORWARD politikom DROP — tako rade neke distribucije i većina očvrsnutih slika — paket se odbacuje na prolazu, a greška koju aplikacija ispiše ne govori ništa o filtriranju.

Pročitajte lanac prije nego što bilo šta dodate:

iptables -S FORWARD
nft list chain inet filter forward

Zatim propustite promet u oba smjera, s brojačima, da možete vidjeti je li pravilo ikada uparilo:

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'

Pravilo s nula brojača paketa nije na putu. Ili se imena sučelja razlikuju od pretpostavljenih, ili je ranije pravilo u lancu prihvatilo, odbacilo ili vratilo paket prvo. Popravite redoslijed, ne tekst pravila.

Povratni promet je polovina koju ljudi zaborave. Pravilo povratka treba isto veth ime plus uparivanje stanja veze, ili obično prihvatanje sučelja ako politiku držite otvorenom. Dodajte samo odlazno pravilo i izvorni simptom se vraća, a vaše novo pravilo tamo stoji i izgleda ispravno.

Držite pravila označavanja tunela dalje od novog puta

Ovaj korak pretvara funkcionalan imenski prostor u onaj koji curi. WireGuard postavke obično instaliraju politiku vatrozidne oznake plus vlastita pravila rutiranja i namjensku tablicu, pa neoznačeni paketi padaju na glavnu tablicu dok označeni koriste tablicu tunela. Proslijeđeni promet iz imenskog prostora procjenjuje se prema političkom rutiranju na izlazu i, ovisno o tome kako su ta pravila napisana, može pasti u tablicu tunela.

Dva dodatka razdvajaju puteve. Vratite se rano u mangle lancu za podmrežu imenskog prostora i dodajte pravilo zasnovano na izvoru koje tu podmrežu stavlja u glavnu tablicu:

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 stoji ispred pravila tunela na mom hostu, pa za taj izvor odlučuje obična tablica. Ne kopirajte broj slijepo: prioriteti koje wg-quick instalira razlikuju se između verzija i između IPv4 i IPv6 postavki, pa pokrenite ip rule show i odaberite prioritet koji pada ispred pravila tunela na vašem stroju.

Provjerite s pretragom specifičnom za izvor umjesto da vjerujete listi pravila:

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

Ako prva naredba prijavi WireGuard sučelje, novo pravilo još nije ispred politike tunela. Ako prijavi WAN sučelje dok druga još pokazuje veth zadanu rutu, host i imenski prostor se ne slažu i treba ponovno pročitati obje tablice rutiranja.

Pokrenite proces koji otvara vezu

Pokretanje naredbe je jedan red, ali pokrenite proces koji stvarno stvara socket.ip netns exec clearnet curl -s https://ifconfig.me je najmanji iskreni test: pokazuje adresu koju imenski prostor predstavlja svijetu, a ne onu koju bi host koristio.

Za servis prikačite imenski prostor po putanji da proces ostane u njemu cijeli život:

[Service]
NetworkNamespacePath=/run/netns/clearnet

Grafičke aplikacije su mjesto gdje jednolinijski pristup tiho pada. Preglednik pokrenut iz menija često preda zahtjev instanci koja već radi izvan imenskog prostora, pa se novi prozor pojavi a promet i dalje izlazi kroz tunel. Dajte mu zaseban profil da se nova instanca stvarno stvori, pa provjerite kontekst procesa umjesto da nagađate:

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

Dva izlaza moraju se podudarati. Ista provjera radi za svaki dugotrajni program i vrijedi je uraditi jednom po aplikaciji umjesto pretpostaviti da je pokretač uradio što ste mislili.

Razrješavanje imena traži vlastitu odluku. Stvaranje imenskog prostora ne daje mu konfiguraciju resolvera; datoteke po imenskom prostoru podržane su kroz /etc/netns/<name>/resolv.conf a bez njih nasljeđujete ponašanje koje se lako pogrešno pročita. IPv6 traži isti tretman: ako imenski prostor nema v6 zadanu rutu dok aplikacija preferira v6, zahtjevi mogu zapeti prije povratka, što izgleda kao pokvaren tunel.

Provjerite okvir, ne samo izlaznu adresu

Funkcionalna javna adresa dokazuje rutu, ne cijeli zahtjev. Prođite kroz ostatak ovim redom:

• ip netns exec clearnet ip route get 1.1.1.1 pokazuje veth zadanu rutu, ne WireGuard sučelje.
• FORWARD brojači na oba pravila rastu dok zahtjev traje.
• Proces aplikacije prijavljuje inode imenskog prostora koji očekujete.
• Nakon ponovnog pokretanja imenski prostor postoji prije nego servis krene; unit koji se pokrene ranije pada ili, još gore, radi izvan imenskog prostora.

Zatim odlučite šta treba da se dogodi kada tunel padne. Imenski prostor nastavlja raditi, što je cilj vježbe i ujedno rizik: izuzeti program ostaje povezan dok sve ostalo staje. Zapišite to kao odluku politike i budite jasni oko toga što izuzeće ne pokriva — identitet računa, sačuvano stanje preglednika i vaš DNS pružalac svi stoje izvan opsega mrežnog imenskog prostora, a tretiranje izuzeća kao anonimnosti je greška koja nadživi konfiguraciju.