Hvernig keyra má eitt Linux-ferli utan WireGuard-göng

Þú getur ekki undanþegið forrit frá WireGuard-hýsli með fullri göng með því að breyta leiðum. Leiðir velja slóð eftir áfangastað, og það sem þú vilt undanþiggja er ferli, svo kjarninn hefur ekkert til að passa við. Vinnanleg aðferð er að gefa því ferli eigið netumhverfi: nafnrými með eigin tengi, eigin vistföngum og eigin sjálfgefinni leið, tengdu hýslinu með veth-pari. Ég keyrði þetta á Ubuntu 24.04 með wireguard-tools 1.0.20210914, og nafnrýmið var aldrei vandamálið — framsendingarstefna hýsilsins og merkingarreglur ganganna voru það.

Veldu fyrst hvers konar umhverfi þú þarft

Í reynd koma tvö form fyrir. Ef hýsillinn keyrir full göng og eitt forrit á að fara út um ISP-slóðina, byggir þú annað nafnrými, tengir það hýslinu og lætur hýsilinn framsenda og þýða umferðina fyrir það. Ef nafnrými ber þegar VPN-tengi og þú þarft aðeins skipun sem er ræst inni í því, er þetta venjulega tilfellið ip netns exec og mest af leiðavinnunni er þegar búin.

Ekkert formanna gefur þér reglu sem er bundin við eitt ferlisauðkenni. Netfilter passar vistföng, gáttir, merki og tengi; það er engin leiðatafla fyrir hvert ferli. Merking getur stýrt umferð, en merkja þarf pakka sem þú hefur þegar greint, og það er sama vandamálið einu lagi neðar. Nafnrými aðskilur allan stakkinn fyrir það ferlatré, og þess vegna er þetta venjulega svarið.

Ef krafan er í raun sú að ekkert fari út úr göngunum, stöðvaðu göngin í staðinn. Nafnrýmið er til fyrir blandaða tilfellið: eitt forrit út, allt annað inn, á sömu vél, á sama tíma.

Byggðu annað umhverfið og tengdu það hýslinu

Skýringarmynd: hýsillinn hefur WireGuard-tengi sem ber sjálfgefnu leiðina, og netnafnrými sem heitir clearnet tengt hýslinu með veth-pari. Vistföngin hér að neðan eru dæmi.

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

Þetta nafnrými getur nú náð til hýsilsins og einskis annars. Hýsillinn verður að framsenda umferðina og endurskrifa upprunavistfangið, því 192.168.100.0/24 er einkaaðgangur og leiðarinn ofar hefur enga leið til baka inn í það:

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

Staðfestu hlið nafnrýmisins áður en þú heldur áfram.ip netns exec clearnet ip route ætti að sýna veth-leiðina og sjálfgefnu leiðina gegnum 192.168.100.1, og ping á það vistfang ætti að svara. Ef ping á vistfang hýsilsins mistekst eru vistföngin eða staða tengilsins röng og engin eldveggjarregla mun hjálpa.

Þegar nöfn leysast en ekkert kemur til baka, lestu FORWARD

Klassíska bilunin lítur út eins og leiðarvilla: nafnrýmið leysir nafn, pakkinn fer út og ekkert svar berst. Á hýslum með FORWARD-stefnu DROP — nokkrar dreifingar og flest harðgerð ímyndir gera það — er pakkanum hent á leiðinni, og villan sem forritið prentar segir ekkert um síun.

Lestu keðjuna áður en þú bætir einhverju við:

iptables -S FORWARD
nft list chain inet filter forward

Leyfðu síðan umferðinni í báðar áttir, með teljurum, svo þú sjáir hvort reglan hefur einhvern tíma passað:

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'

Regla með núll pakkateljara er ekki á leiðinni. Annaðhvort eru tengjanöfnin önnur en þú gerðir ráð fyrir, eða fyrri regla í keðjunni tók við, henti eða skilaði pakkanum fyrst. Lagaðu röðina, ekki texta reglunnar.

Svarumferðin er sá helmingur sem fólk gleymir. Bakreglan þarf sama veth-nafn auk samsvörunar á tengingarstöðu, eða einfalda tengisviðtöku ef þú heldur stefnunni opinni. Bættu aðeins útleiðarreglunni við og upprunalega einkennið kemur aftur, með nýju regluna þína þar og virðist rétt.

Haltu merkingarreglum ganganna fjarri nýju leiðinni

Þetta skref breytir virku nafnrými í lekjandi. WireGuard-uppsetningar setja venjulega upp eldveggjarmerkingarstefnu ásamt eigin leiðarreglum og sérstakri töflu, svo ómerktir pakkar falla aftur í aðaltöfluna á meðan merktir pakkar nota göngutöfluna. Framsend umferð frá nafnrýminu er metin gegn stefnuleiðsögn á útleið, og eftir því hvernig þessar reglur voru skrifaðar getur hún lent í göngutöflunni.

Tvær viðbætur aðskilja leiðirnar. Farðu snemma til baka í mangle-keðjunni fyrir undirnet nafnrýmisins, og bættu við reglu sem byggir á uppruna og setur það undirnet í aðaltöfluna:

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

Forgangur 100 raðast framar leiðarreglum ganganna á hýslinum mínum, svo venjulega taflan ræður fyrir þann uppruna. Ekki afrita töluna blint: forgangarnir sem wg-quick setur upp eru mismunandi milli útgáfa og milli IPv4- og IPv6-uppsetninga, svo keyrðu ip rule show og veldu forgang sem lendir framan við leiðarreglur ganganna á þinni vél.

Sannreyndu með upprunasérstakri leit í stað þess að treysta reglulistanum:

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

Ef fyrsta skipunin tilkynnir WireGuard-tengið er nýja reglan ekki komin framan við stefnu ganganna. Ef hún tilkynnir WAN-tengið á meðan sú seinni sýnir enn sjálfgefnu veth-leiðina, eru hýsillinn og nafnrýmið ekki sammála og þú ættir að lesa báðar leiðatöflurnar aftur.

Ræstu ferlið sem opnar tenginguna

Að ræsa skipunina er ein lína, en ræstu ferlið sem býr í raun til sokkinn.ip netns exec clearnet curl -s https://ifconfig.me er minnsta heiðarlega prófið: það sýnir vistfangið sem nafnrýmið sýnir heiminum, ekki það sem hýsillinn myndi nota.

Fyrir þjónustu skaltu hengja nafnrýmið á slóðina svo ferlið haldist í því alla sína ævi:

[Service]
NetworkNamespacePath=/run/netns/clearnet

Skjáborðsforrit eru þar sem einnar línu aðferðin bregst hljóðlega. Vafri sem er ræstur úr valmynd afhendir beiðnina oft til tilviks sem er þegar í keyrslu utan nafnrýmisins, svo nýi glugginn birtist og umferðin fer samt út um göngin. Gefðu honum sérstakt prófíl svo nýtt tilvik verði í raun búið til, og athugaðu síðan samhengi ferlisins í stað þess að giska:

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

Úttökin tvö verða að stemma. Sama athugun virkar fyrir hvert langlíft forrit, og það er þess virði að gera hana einu sinni fyrir hvert forrit í stað þess að ganga út frá því að ræsirinn hafi gert það sem þú áttir við.

Nafnaleysing þarf sína eigin ákvörðun. Að búa til nafnrými gefur því ekki uppsetningu leysanda; skrár fyrir hvert nafnrými eru studdar í gegnum /etc/netns/<name>/resolv.conf og án einnar erfir þú hegðun sem er auðvelt að lesa rangt. IPv6 þarf sömu meðferð: ef nafnrýmið hefur enga sjálfgefna v6-leið á meðan forritið kýs v6, geta beiðnir stöðvast áður en dregið er í land, sem lítur út eins og brotin göng.

Athugaðu umgjörðina, ekki bara útgangsvistfangið

Virkandi opinbert vistfang sannar leiðina, ekki alla kröfuna. Farðu í gegnum restina í þessari röð:

• ip netns exec clearnet ip route get 1.1.1.1 sýnir sjálfgefnu veth-leiðina, ekki WireGuard-tengið.
• FORWARD-teljararnir á báðum reglum hækka á meðan beiðni er í gangi.
• Ferli forritsins tilkynnir inode nafnrýmisins sem þú býst við.
• Eftir endurræsingu er nafnrýmið til áður en þjónustan byrjar; eining sem keyrir fyrr mistekst eða, verra, keyrir utan nafnrýmisins.

Ákveddu síðan hvað eigi að gerast þegar göngin falla. Nafnrýmið heldur áfram að virka, sem er tilgangur æfingarinnar og jafnframt áhættan: undanþegna forritið helst tengt á meðan allt annað stoppar. Skráðu það sem stefnuákvörðun og vertu skýr um hvað undanþágan nær ekki yfir — auðkenni reiknings, vistað vafraástand og DNS-veitandinn þinn standa öll utan gildissviðs netnafnrýmis, og að líta á undanþáguna sem nafnleysi er mistökin sem lifa uppsetninguna.