Kiel ruli unu Linux-procezon ekster WireGuard-tunelo

Vi ne povas escepti programon de WireGuard-gastiganto kun plena tunelo per redaktado de itineroj. Itineroj elektas vojon laŭ celo, sed tio, kion vi volas escepti, estas procezo, do la kerno havas nenion por kongruigi. La farebla aliro estas doni al tiu procezo sian propran retan kuntekston: nomspaco kun propra interfaco, propraj adresoj kaj propra defaŭlta itinero, ligita al la gastiganto per veth-paro. Mi rulis tion sur Ubuntu 24.04 kun wireguard-tools 1.0.20210914, kaj la nomspaco neniam estis la problemo — la plusenda politiko de la gastiganto kaj la markaj reguloj de la tunelo estis.

Unue elektu la specon de kunteksto, kiun vi bezonas

En praktiko aperas du formoj. Se la gastiganto rulas plenan tunelon kaj unu programo devas eliri laŭ la ISP-vojo, vi konstruas duan nomspacon, ligas ĝin al la gastiganto kaj lasas la gastiganton plusendi kaj traduki la trafikon por ĝi. Se nomspaco jam portas VPN-interfacon kaj vi bezonas nur komandon startigitan ene de ĝi, tio estas la ordinara ip netns exec kazo, kaj la plej granda parto de la itinera laboro jam estas farita.

Neniu el la du formoj donas al vi regulon limigitan al unu proceza identigilo. Netfilter kongruigas adresojn, pordojn, markojn kaj interfacojn; ne ekzistas itinera tabelo por ĉiu procezo. Markado povas direkti trafikon, sed la marko devas esti aplikata al pakoj, kiujn vi jam identigis, kaj tio estas la sama problemo unu tavolon pli malsupre. Nomspaco apartigas la tutan stakon por tiu proceza arbo, kaj tial ĝi estas la kutima respondo.

Se la postulo vere estas, ke nenio eliru la tunelon, haltigu la tunelon anstataŭe. La nomspaco ekzistas por la miksita kazo: unu programo eksteren, ĉio alia enen, sur la sama maŝino, en la sama tempo.

Konstruu la duan kuntekston kaj ligu ĝin al la gastiganto

Ilustra aranĝo: la gastiganto havas WireGuard-interfacon portantan la defaŭltan itineron, kaj retan nomspacon nomatan clearnet ligitan al la gastiganto per veth-paro. La adresoj sube estas ekzemploj.

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

Tiu nomspaco nun povas atingi la gastiganton kaj nenion alian. La gastiganto devas plusendi la trafikon kaj reskribi la fontadreson, ĉar 192.168.100.0/24 estas privata kaj la supra enkursigilo havas neniun itineron reen en ĝin:

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

Konfirmu la flankon de la nomspaco antaŭ ol daŭrigi.ip netns exec clearnet ip route devus montri la veth-itineron kaj la defaŭltan itineron tra 192.168.100.1, kaj ping al tiu adreso devus respondi. Se ping al la gastiganta adreso malsukcesas, la adresoj aŭ la stato de la ligilo estas malĝustaj kaj neniu fajroŝirma regulo helpos.

Kiam nomoj solviĝas sed nenio revenas, legu FORWARD

La klasika malsukceso aspektas kiel itinera cimo: la nomspaco solvas nomon, la pako eliras kaj neniu respondo iam alvenas. Sur gastigantoj kun FORWARD-politiko DROP — kelkaj distribuaĵoj kaj la plej multaj malmoligitaj bildoj faras tion — la pako estas forĵetata survoje, kaj la eraro, kiun la programo presas, diras nenion pri filtrado.

Legu la ĉenon antaŭ ol aldoni ion:

iptables -S FORWARD
nft list chain inet filter forward

Poste permesu la trafikon en ambaŭ direktojn, kun nombriloj, por ke vi povu vidi, ĉu la regulo iam kongruis:

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'

Regulo kun nula paka nombrilo ne estas en la vojo. Aŭ la interfacaj nomoj diferencas de tio, kion vi supozis, aŭ pli frua regulo en la ĉeno akceptis, forĵetis aŭ redonis la pakon unue. Riparu la ordon, ne la tekston de la regulo.

Responda trafiko estas la duono, kiun homoj forgesas. La redona regulo bezonas la saman veth-nomon plus kongruon de konekta stato, aŭ simplan interfacan akcepton, se vi tenas la politikon malferma. Aldonu nur la eliran regulon kaj la origina simptomo revenas, dum via nova regulo staras tie kaj aspektas ĝusta.

Tenu la markajn regulojn de la tunelo for de la nova vojo

Ĉi tiu paŝo transformas funkciantan nomspacon en likantan. WireGuard-agordoj kutime instalas fajroŝirman markopolitikon kun propraj itinaj reguloj kaj dediĉita tabelo, do nemarkitaj pakoj falas reen al la ĉefa tabelo dum markitaj pakoj uzas la tunelan tabelon. Plusendita trafiko el la nomspaco estas taksata laŭ politika itinado survoje eksteren, kaj depende de tio, kiel tiuj reguloj estis skribitaj, ĝi povas eniri la tunelan tabelon.

Du aldonaĵoj apartigas la vojojn. Revenu frue en la mangle-ĉeno por la subreto de la nomspaco, kaj aldonu font-bazitan regulon, kiu metas tiun subreton en la ĉefan tabelon:

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

Prioritato 100 ordiĝas antaŭ la tunelaj reguloj sur mia gastiganto, do la ordinara tabelo decidas por tiu fonto. Ne kopiu la nombron blinde: la prioritatoj, kiujn wg-quick instalas, diferencas inter versioj kaj inter la agordoj por IPv4 kaj IPv6, do rulu ip rule show kaj elektu prioritaton, kiu falas antaŭ la tunelaj reguloj sur via maŝino.

Kontrolu per font-specifa serĉo anstataŭ fidi la reguloliston:

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

Se la unua komando raportas la WireGuard-interfacon, la nova regulo ankoraŭ ne estas antaŭ la tunela politiko. Se ĝi raportas la WAN-interfacon dum la dua ankoraŭ montras la veth-defaŭlton, la gastiganto kaj la nomspaco malkonsentas kaj vi devus relegi ambaŭ itinajn tabelojn.

Startigu la procezon, kiu malfermas la konekton

Startigi la komandon estas unu linio, sed startigu la procezon, kiu efektive kreas la poŝon.ip netns exec clearnet curl -s https://ifconfig.me estas la plej malgranda honesta testo: ĝi montras la adreson, kiun la nomspaco prezentas al la mondo, ne tiun, kiun la gastiganto uzus.

Por servo, alligu la nomspacon laŭ vojo, por ke la procezo restu en ĝi dum sia tuta vivo:

[Service]
NetworkNamespacePath=/run/netns/clearnet

Grafikaj aplikaĵoj estas kie la unu-linia aliro silente malsukcesas. Retumilo lanĉita el menuo ofte transdonas la peton al kazo, kiu jam ruliĝas ekster la nomspaco, do la nova fenestro aperas kaj la trafiko ankoraŭ eliras tra la tunelo. Donu al ĝi apartan profilon, por ke nova kazo vere kreiĝu, kaj poste kontrolu la procezan kuntekston anstataŭ diveni:

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

La du eligoj devas kongrui. La sama kontrolo funkcias por iu ajn longdaŭra programo, kaj indas fari ĝin unufoje por aplikaĵo anstataŭ supozi, ke la lanĉilo faris tion, kion vi celis.

Nom-solvado bezonas sian propran decidon. Krei nomspacon ne donas al ĝi solvilan agordon; dosieroj por ĉiu nomspaco estas subtenataj per /etc/netns/<name>/resolv.conf kaj sen unu vi heredas konduton, kiun oni facile mislegas. IPv6 bezonas la saman traktadon: se la nomspaco havas neniun v6-defaŭltan itineron dum la aplikaĵo preferas v6, petoj povas halti antaŭ ol fali reen, kio aspektas kiel rompita tunelo.

Kontrolu la kadrigon, ne nur la eliran adreson

Funkcianta publika adreso pruvas la itineron, ne la tutan postulon. Trairu la reston en ĉi tiu ordo:

• ip netns exec clearnet ip route get 1.1.1.1 montras la veth-defaŭlton, ne la WireGuard-interfacon.
• La FORWARD-nombriloj sur ambaŭ reguloj kreskas dum peto ruliĝas.
• La aplika procezo raportas la nomspacan inodon, kiun vi atendas.
• Post restarto la nomspaco ekzistas antaŭ ol la servo startas; unuo, kiu ruliĝas pli frue, malsukcesas aŭ, pli malbone, ruliĝas ekster la nomspaco.

Poste decidu, kio devus okazi, kiam la tunelo falas. La nomspaco daŭre funkcias, kio estas la celo de la ekzerco kaj ankaŭ la risko: la esceptita programo restas konektita dum ĉio alia haltas. Registru tion kiel politikan decidon kaj estu klara pri tio, kion la escepto ne kovras — konta identeco, konservita retumila stato kaj via DNS-provizanto ĉiuj staras ekster la amplekso de reta nomspaco, kaj trakti la escepton kiel anonimecon estas la eraro, kiu postvivas la agordon.