Programa ne morete izvzeti iz gostitelja WireGuard s polnim tunelom z urejanjem poti. Poti izbirajo pot glede na cilj, in kar želite izvzeti, je proces, zato jedro nima česa primerjati. Izvedljiv pristop je, da temu procesu daste lasten omrežni kontekst: imenski prostor z lastnim vmesnikom, naslovi in privzeto potjo, povezan z gostiteljem s parom veth. To sem zagnal na Ubuntu 24.04 z wireguard-tools 1.0.20210914 in imenski prostor ni bil nikoli težava — težava sta bili politika posredovanja gostitelja in pravila označevanja tunela.

Najprej izberite vrsto konteksta, ki ga potrebujete

V praksi se pojavita dve obliki. Če gostitelj poganja polni tunel in mora en program oditi po poti ISP, zgradite drugi imenski prostor, ga povežete z gostiteljem in pustite gostitelju, da zanj posreduje in prevaja promet. Če imenski prostor že nosi vmesnik VPN in potrebujete le ukaz, zagnan v njem, je to običajni primer ip netns exec in večina dela s potmi je že opravljenega.

Nobena oblika vam ne da pravila, omejenega na eno identifikacijo procesa. Netfilter primerja naslove, vrata, oznake in vmesnike; tabele usmerjanja na proces ni. Označevanje lahko usmerja promet, a oznako je treba postaviti na pakete, ki ste jih že prepoznali, in to je ista težava eno plast nižje. Imenski prostor loči celoten sklad za to drevo procesov, zato je to običajen odgovor.

Če je zahteva resnično ta, da iz tunela nič ne pride, ustavite tunel. Imenski prostor obstaja za mešani primer: en program ven, vse ostalo noter, na istem stroju, ob istem času.

Zgradite drugi kontekst in ga povežite z gostiteljem

Ilustrativna postavitev: gostitelj ima vmesnik WireGuard, ki nosi privzeto pot, in omrežni imenski prostor z imenom clearnet povezan z gostiteljem s parom veth. Naslovi spodaj so primeri.

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

Ta imenski prostor lahko zdaj doseže gostitelja in nič drugega. Gostitelj mora posredovati promet in prepisati izvorni naslov, ker je 192.168.100.0/24 zaseben in nadrejeni usmerjevalnik nima poti nazaj vanj:

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

Preden nadaljujete, potrdite stran imenskega prostora.ip netns exec clearnet ip route bi moralo pokazati pot veth in privzeto pot prek 192.168.100.1, ping na ta naslov pa bi moral odgovoriti. Če ping na naslov gostitelja ne uspe, so naslovi ali stanje povezave napačni in nobeno pravilo požarnega zidu ne bo pomagalo.

Ko se imena razrešijo, a nič se ne vrne, preberite FORWARD

Klasična napaka je videti kot hrošč pri usmerjanju: imenski prostor razreši ime, paket odide in odgovor nikoli ne pride. Na gostiteljih s politiko FORWARD DROP — tako počne več distribucij in večina utrjenih podob — se paket na poti zavrže, napaka, ki jo natisne aplikacija, pa o filtriranju ne pove nič.

Preberite verigo, preden kar koli dodate:

iptables -S FORWARD
nft list chain inet filter forward

Nato spustite promet v obe smeri, s števci, da boste vedeli, ali se je pravilo kdaj ujemalo:

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 z ničelnim števcem paketov ni na poti. Ali se imena vmesnikov razlikujejo od predpostavljenih, ali je prejšnje pravilo v verigi paket najprej sprejelo, zavrglo ali vrnilo. Popravite vrstni red, ne besedila pravila.

Odgovorni promet je polovica, ki jo ljudje pozabijo. Pravilo vrnitve potrebuje isto ime veth plus ujemanje stanja povezave ali običajno sprejetje vmesnika, če politiko držite odprto. Dodajte samo odhodno pravilo in prvotni simptom se vrne, vaše novo pravilo pa stoji tam in je videti pravilno.

Držite pravila označevanja tunela proč od nove poti

Ta korak spremeni delujoči imenski prostor v puščajočega. Namestitve WireGuard običajno namestijo politiko oznake požarnega zidu skupaj z lastnimi pravili usmerjanja in namensko tabelo, zato neoznačeni paketi padejo nazaj v glavno tabelo, označeni pa uporabljajo tabelo tunela. Posredovani promet iz imenskega prostora se ob odhodu ocenjuje glede na politično usmerjanje in glede na to, kako so bila ta pravila napisana, lahko pristane v tabeli tunela.

Dva dodatka ločita poti. Vrnite se zgodaj v verigi mangle za podomrežje imenskega prostora in dodajte pravilo na podlagi vira, ki to podomrežje postavi v glavno tabelo:

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

Prioriteta 100 se na mojem gostitelju razvrsti pred pravili tunela, zato za ta vir odloča običajna tabela. Številke ne kopirajte na slepo: prioritete, ki jih wg-quick namesti, se razlikujejo med različicami in med nastavitvami IPv4 in IPv6, zato zaženite ip rule show in izberite prioriteto, ki na vašem stroju pade pred pravila tunela.

Preverite s iskanjem, specifičnim za vir namesto da bi zaupali seznamu pravil:

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

Če prvi ukaz sporoči vmesnik WireGuard, novo pravilo še ni pred politiko tunela. Če sporoči vmesnik WAN, medtem ko drugi še vedno kaže privzeto pot veth, se gostitelj in imenski prostor ne strinjata in obe tabeli usmerjanja bi morali prebrati znova.

Zaženite proces, ki odpre povezavo

Zagnati ukaz je ena vrstica, a zaženite proces, ki resnično ustvari vtičnico.ip netns exec clearnet curl -s https://ifconfig.me je najmanjši pošten test: pokaže naslov, ki ga imenski prostor predstavi svetu, ne tistega, ki bi ga uporabil gostitelj.

Za storitev pritrdite imenski prostor po poti, da proces ostane v njem vse življenje:

[Service]
NetworkNamespacePath=/run/netns/clearnet

Grafične aplikacije so kraj, kjer pristop z eno vrstico tiho odpove. Brskalnik, zagnan iz menija, pogosto preda zahtevo primerku, ki že teče zunaj imenskega prostora, zato se novo okno prikaže in promet še vedno odhaja skozi tunel. Dajte mu ločen profil, da se resnično ustvari nov primerek, nato preverite kontekst procesa, namesto da ugibate:

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

Oba izhoda se morata ujemati. Ista kontrola deluje za vsak dolgo delujoč program in vredno jo je opraviti enkrat na aplikacijo, namesto da bi predpostavili, da je zaganjalnik naredil, kar ste mislili.

Razreševanje imen potrebuje lastno odločitev. Ustvarjanje imenskega prostora mu ne da konfiguracije razreševalnika; datoteke za posamezni imenski prostor so podprte prek /etc/netns/<name>/resolv.conf brez nje pa podedujete vedenje, ki se zlahka napačno prebere. IPv6 potrebuje enako obravnavo: če imenski prostor nima privzete poti v6, medtem ko aplikacija raje uporablja v6, se zahteve lahko zataknejo, preden se vrnejo nazaj, kar je videti kot pokvarjen tunel.

Preverite okvir, ne le izhodnega naslova

Delujoč javni naslov dokazuje pot, ne cele zahteve. Prehodite preostanek v tem vrstnem redu:

  • ip netns exec clearnet ip route get 1.1.1.1 pokaže privzeto pot veth, ne vmesnika WireGuard.
  • Števca FORWARD na obeh pravilih naraščata, medtem ko zahteva teče.
  • Proces aplikacije sporoči inode imenskega prostora, ki ga pričakujete.
  • Po ponovnem zagonu imenski prostor obstaja, preden se storitev zažene; enota, ki se zažene prej, odpove ali, še huje, teče zunaj imenskega prostora.

Nato odločite, kaj naj se zgodi, ko tunel pade. Imenski prostor deluje naprej, kar je smisel vaje in hkrati tveganje: izvzeti program ostane povezan, medtem ko se vse drugo ustavi. Zapišite to kot odločitev politike in bodite jasni glede tega, česa izjema ne pokriva — identiteta računa, shranjeno stanje brskalnika in vaš ponudnik DNS so vsi zunaj obsega omrežnega imenskega prostora, in obravnavanje izjeme kot anonimnosti je napaka, ki preživi konfiguracijo.

Sorodni članki