Te ei saa programmi täistunneliga WireGuardi hostist vabastada marsruute redigeerides. Marsruudid valivad tee sihtkoha järgi, aga see, mida vabastada tahate, on protsess, nii et kernelil pole millegagi sobitada. Toimiv lähenemine on anda sellele protsessile oma võrgukontekst: nimeruum oma liidese, aadresside ja vaikimisi marsruudiga, mis on hostiga ühendatud veth-paari kaudu. Käivitasin selle Ubuntu 24.04-s koos wireguard-tools 1.0.20210914-ga ja nimeruum ei olnud kunagi probleem — probleemiks olid hosti edastuspoliitika ja tunneli märgistusreeglid.

Valige esmalt vajalik kontekstitüüp

Praktikas esineb kaks vormi. Kui host jooksutab täistunnelit ja üks programm peab väljuma ISP-teed pidi, ehitate teise nimeruumi, ühendate selle hostiga ja lasete hostil selle eest edastada ja tõlkida. Kui nimeruumil on juba VPN-liides ja vajate ainult selle sees käivitatavat käsku, on see tavaline ip netns exec juhtum ja suurem osa marsruutimistööst on juba tehtud.

Kumbki vorm ei anna teile ühe protsessi ID-ga piiratud reeglit. Netfilter sobitab aadresse, porte, märgiseid ja liideseid; protsessipõhist marsruutimistabelit ei ole. Märgistamine saab liiklust suunata, kuid märgis tuleb panna pakettidele, mille olete juba tuvastanud, ja see on sama probleem ühe kihi võrra allpool. Nimeruum eraldab kogu virna selle protsessipuu jaoks ja seetõttu on see tavaline vastus.

Kui nõue on tõesti, et tunnelist ei välju midagi, peatage selle asemel tunnel. Nimeruum on mõeldud segajuhtumi jaoks: üks programm välja, kõik muu sisse, samas masinas, samal ajal.

Ehitage teine kontekst ja ühendage see hostiga

Illustreeriv paigutus: hostil on WireGuardi liides, mis kannab vaikimisi marsruuti, ja võrgu nimeruum nimega clearnet mis on hostiga ühendatud veth-paari kaudu. Allpool olevad aadressid on näited.

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

See nimeruum pääseb nüüd hostile ligi ja mitte millelegi muule. Host peab liiklust edastama ja lähteaadressi ümber kirjutama, sest 192.168.100.0/24 on privaatne ja ülemisel ruuteril pole sinna tagasi marsruuti:

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

Kinnitage nimeruumi pool enne edasiminekut.ip netns exec clearnet ip route peaks näitama veth-marsruuti ja vaikimisi marsruuti läbi 192.168.100.1 ning ping sellele aadressile peaks vastama. Kui ping hosti aadressile ebaõnnestub, on aadressid või lingi olek valed ja ükski tulemüürireegel ei aita.

Kui nimed lahendatakse, aga midagi ei tule tagasi, lugege FORWARD-i

Klassikaline tõrge näeb välja nagu marsruutimisviga: nimeruum lahendab nime, pakett väljub ja vastust ei tule kunagi. Hostidel, kus FORWARD-poliitika on DROP — nii teevad mitmed distributsioonid ja enamik karastatud kujutisi — jäetakse pakett teel maha ja rakenduse prinditav viga ei ütle filtreerimise kohta midagi.

Lugege ahelat enne millegi lisamist:

iptables -S FORWARD
nft list chain inet filter forward

Seejärel lubage liiklus mõlemas suunas, loenduritega, et näha, kas reegel kunagi sobis:

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'

Nullpaketiloenduriga reegel ei ole teel. Kas liidesenimed erinevad oletatust või on mõni varasem reegel ahelas paketi esimesena vastu võtnud, maha jätnud või tagastanud. Parandage järjekord, mitte reegli tekst.

Vastusliiklus on see pool, mille inimesed unustavad. Tagasireegel vajab sama veth-nime pluss ühenduse oleku vastet või tavalist liidese lubamist, kui hoiate poliitika avatuna. Lisage ainult väljuv reegel ja algne sümptom on tagasi, samal ajal kui teie uus reegel seisab seal ja näeb õige välja.

Hoidke tunneli märgistusreeglid uuest teest eemal

See samm muudab töötava nimeruumi lekkivaks. WireGuardi seadistused paigaldavad tavaliselt tulemüüri märgisepoliitika koos oma marsruutimisreeglite ja sihtotstarbelise tabeliga, nii et märgistamata paketid langevad tagasi põhitabelisse, samas kui märgistatud kasutavad tunneli tabelit. Nimeruumist edastatud liiklust hinnatakse väljumisel poliitilise marsruutimise vastu ja sõltuvalt sellest, kuidas need reeglid kirjutati, võib see sattuda tunneli tabelisse.

Kaks täiendust eraldavad teed. Pöörduge nimeruumi alavõrgu jaoks mangle-ahelas varakult tagasi ja lisage allikapõhine reegel, mis paneb selle alavõrgu põhitabelisse:

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

Prioriteet 100 järjestub minu hostil tunneli reeglitest ette, seega otsustab selle allika jaoks tavaline tabel. Ärge kopeerige numbrit pimesi: prioriteedid, mille wg-quick paigaldab, erinevad versioonide ja IPv4 ning IPv6 seadistuste vahel, seega käivitage ip rule show ja valige prioriteet, mis jääb teie masinas tunneli reeglitest ette.

Kontrollige allikapõhise otsinguga reeglite nimekirja usaldamise asemel:

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

Kui esimene käsk teatab WireGuardi liidesest, ei ole uus reegel veel tunneli poliitika ees. Kui see teatab WAN-liidesest, samal ajal kui teine näitab endiselt veth vaikimisi marsruuti, on host ja nimeruum eriarvamusel ning peaksite mõlemad marsruutimistabelid uuesti läbi lugema.

Käivitage protsess, mis ühenduse avab

Käsu käivitamine on üks rida, kuid käivitage protsess, mis pistiku tegelikult loob.ip netns exec clearnet curl -s https://ifconfig.me on väikseim aus test: see näitab aadressi, mille nimeruum maailmale esitab, mitte seda, mida host kasutaks.

Teenuse puhul kinnitage nimeruum tee kaudu, et protsess jääks sinna kogu oma elueaks:

[Service]
NetworkNamespacePath=/run/netns/clearnet

Graafilised rakendused on koht, kus üherealise lähenemine vaikselt ebaõnnestub. Menüüst käivitatud brauser annab päringu sageli juba väljaspool nimeruumi töötavale eksemplarile, nii et uus aken ilmub ja liiklus väljub endiselt tunneli kaudu. Andke sellele eraldi profiil, et uus eksemplar tõesti loodaks, ja seejärel kontrollige protsessi konteksti, selle asemel et oletada:

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

Kaks väljundit peavad ühtima. Sama kontroll töötab iga pikalt töötava programmi puhul ja seda tasub teha üks kord rakenduse kohta, selle asemel et eeldada, et käivitaja tegi seda, mida mõtlesite.

Nimede lahendamine vajab omaette otsust. Nimeruumi loomine ei anna sellele lahendaja konfiguratsiooni; nimeruumipõhiseid faile toetatakse /etc/netns/<name>/resolv.conf kaudu ja ilma selleta pärite käitumise, mida on lihtne valesti lugeda. IPv6 vajab sama kohtlemist: kui nimeruumil pole v6 vaikimisi marsruuti, samal ajal kui rakendus eelistab v6, võivad päringud enne taganemist takerduda, mis näeb välja nagu katkine tunnel.

Kontrollige raamistust, mitte ainult väljumisaadressi

Töötav avalik aadress tõestab marsruuti, mitte kogu nõuet. Käige ülejäänu läbi selles järjekorras:

  • ip netns exec clearnet ip route get 1.1.1.1 näitab veth vaikimisi marsruuti, mitte WireGuardi liidest.
  • Mõlema reegli FORWARD-loendurid kasvavad päringu töötamise ajal.
  • Rakenduse protsess teatab nimeruumi inode'i, mida ootate.
  • Pärast taaskäivitust on nimeruum olemas enne teenuse käivitumist; varem töötav unit ebaõnnestub või, mis hullem, töötab väljaspool nimeruumi.

Seejärel otsustage, mis peaks juhtuma, kui tunnel langeb. Nimeruum töötab edasi, mis on harjutuse mõte ja ühtlasi risk: vabastatud programm jääb ühendatuks, samal ajal kui kõik muu peatub. Kirjutage see poliitikaotsusena üles ja olge selge, mida vabastus ei kata — konto identiteet, salvestatud brauseri olek ja teie DNS-teenusepakkuja asuvad kõik väljaspool võrgu nimeruumi ulatust, ja vabastuse pidamine anonüümsuseks on viga, mis elab seadistusest kauem.

Seotud artiklid