Kā palaist vienu Linux procesu ārpus WireGuard tuneļa

Jūs nevarat atbrīvot programmu no WireGuard saimnieka ar pilnu tuneli, rediģējot maršrutus. Maršruti izvēlas ceļu pēc galamērķa, un tas, ko vēlaties atbrīvot, ir process, tāpēc kodolam nav ar ko salīdzināt. Derīgā pieeja ir dot šim procesam savu tīkla kontekstu: nosaukumvieta ar savu saskarni, adresēm un noklusējuma maršrutu, kas savienota ar saimnieku ar veth pāri. Es to palaidu uz Ubuntu 24.04 ar wireguard-tools 1.0.20210914, un nosaukumvieta nekad nebija problēma — problēma bija saimnieka pārsūtīšanas politika un tuneļa marķēšanas noteikumi.

Vispirms izvēlieties nepieciešamo konteksta veidu

Praksē parādās divas formas. Ja saimnieks darbina pilnu tuneli un vienai programmai jāiziet pa ISP ceļu, jūs veidojat otru nosaukumvietu, savienojat to ar saimnieku un ļaujat saimniekam par to pārsūtīt un pārtulkot datplūsmu. Ja nosaukumvietai jau ir VPN saskarne un jums vajag tikai tajā palaistu komandu, tas ir parastais ip netns exec gadījums, un lielākā daļa maršrutēšanas darba jau ir paveikta.

Neviena no formām nedod noteikumu, kas ierobežots ar vienu procesa ID. Netfilter salīdzina adreses, portus, atzīmes un saskarnes; maršrutēšanas tabulas uz procesu nav. Marķēšana var virzīt datplūsmu, bet atzīme jāuzliek paketēm, kuras jūs jau identificējāt, un tā ir tā pati problēma vienu slāni zemāk. Nosaukumvieta atdala visu steku šim procesu kokam, un tāpēc šī ir ierastā atbilde.

Ja prasība patiešām ir tāda, ka nekas neiziet no tuneļa, tā vietā apturiet tuneli. Nosaukumvieta pastāv jauktajam gadījumam: viena programma ārā, viss pārējais iekšā, tajā pašā mašīnā, tajā pašā laikā.

Izveidojiet otru kontekstu un savienojiet to ar saimnieku

Ilustratīvs izkārtojums: saimniekam ir WireGuard saskarne, kas nes noklusējuma maršrutu, un tīkla nosaukumvieta ar nosaukumu clearnet savienota ar saimnieku ar veth pāri. Tālāk minētās adreses ir piemēri.

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

Šī nosaukumvieta tagad var sasniegt saimnieku un neko citu. Saimniekam jāpārsūta datplūsma un jāpārraksta avota adrese, jo 192.168.100.0/24 ir privāta un augšupējam maršrutētājam nav maršruta atpakaļ tajā:

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

Pirms turpināt, apstipriniet nosaukumvietas pusi.ip netns exec clearnet ip route vajadzētu parādīt veth maršrutu un noklusējuma maršrutu caur 192.168.100.1, un ping uz šo adresi vajadzētu atbildēt. Ja ping uz saimnieka adresi neizdodas, adreses vai saites stāvoklis ir nepareizs, un neviena ugunsmūra noteikums nepalīdzēs.

Kad vārdi tiek atrisināti, bet nekas neatgriežas, lasiet FORWARD

Klasiskā kļūda izskatās kā maršrutēšanas kļūda: nosaukumvieta atrisina vārdu, pakete iziet, un atbilde nekad nepienāk. Saimniekos ar FORWARD politiku DROP — tā dara vairākas distribūcijas un lielākā daļa rūdīto attēlu — pakete tiek atmesta ceļā, un programmas drukātā kļūda neko neizsaka par filtrēšanu.

Pirms kaut ko pievienojat, izlasiet ķēdi:

iptables -S FORWARD
nft list chain inet filter forward

Pēc tam laidiet datplūsmu abos virzienos, ar skaitītājiem, lai jūs varētu pateikt, vai noteikums kādreiz ir saskaņojies:

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'

Noteikums ar nulles pakešu skaitītāju nav ceļā. Vai nu saskarņu nosaukumi atšķiras no jūsu pieņēmuma, vai arī agrāks noteikums ķēdē vispirms pieņēma, atmeta vai atdeva paketi. Izlabojiet secību, nevis noteikuma tekstu.

Atbildes datplūsma ir tā puse, ko cilvēki aizmirst. Atgriešanas noteikumam vajag to pašu veth nosaukumu plus savienojuma stāvokļa atbilstību, vai vienkāršu saskarnes pieņemšanu, ja turat politiku atvērtu. Pievienojiet tikai izejošo noteikumu, un sākotnējais simptoms atgriežas, kamēr jūsu jaunais noteikums stāv tur un izskatās pareizi.

Turiet tuneļa marķēšanas noteikumus prom no jaunā ceļa

Šis solis pārvērš strādājošu nosaukumvietu plūstošā. WireGuard iestatījumi parasti instalē ugunsmūra atzīmes politiku kopā ar saviem maršrutēšanas noteikumiem un īpašu tabulu, tāpēc neatzīmētas paketes atgriežas galvenajā tabulā, bet atzīmētās izmanto tuneļa tabulu. No nosaukumvietas pārsūtītā datplūsma izejot tiek novērtēta pret politikas maršrutēšanu, un atkarībā no tā, kā šie noteikumi tika rakstīti, tā var nonākt tuneļa tabulā.

Divi papildinājumi atdala ceļus. Atgriezieties agri mangle ķēdē nosaukumvietas apakštīklam un pievienojiet avota balstītu noteikumu, kas ievieto šo apakštīklu galvenajā tabulā:

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

Prioritāte 100 manā saimniekā ierindojas pirms tuneļa noteikumiem, tāpēc šim avotam izlemj parastā tabula. Nekopējiet skaitli akli: prioritātes, ko wg-quick instalē, atšķiras starp versijām un starp IPv4 un IPv6 iestatījumiem, tāpēc palaidiet ip rule show un izvēlieties prioritāti, kas jūsu mašīnā atrodas pirms tuneļa noteikumiem.

Pārbaudiet ar avotam specifisku meklēšanu tā vietā, lai paļautos uz noteikumu sarakstu:

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

Ja pirmā komanda ziņo WireGuard saskarni, jaunais noteikums vēl nav pirms tuneļa politikas. Ja tā ziņo WAN saskarni, kamēr otrā joprojām rāda veth noklusējuma maršrutu, saimnieks un nosaukumvieta nav vienisprātis, un jums vajadzētu pārlasīt abas maršrutēšanas tabulas.

Palaidiet procesu, kas atver savienojumu

Komandas palaišana ir viena rinda, bet palaidiet procesu, kas faktiski izveido ligzdu.ip netns exec clearnet curl -s https://ifconfig.me ir mazākais godīgais tests: tas rāda adresi, ko nosaukumvieta parāda pasaulei, nevis to, ko izmantotu saimnieks.

Pakalpojumam pievienojiet nosaukumvietu pēc ceļa, lai process tajā paliktu visu mūžu:

[Service]
NetworkNamespacePath=/run/netns/clearnet

Grafiskās lietotnes ir vieta, kur vienas rindas pieeja klusi neizdodas. Pārlūkprogramma, kas palaista no izvēlnes, bieži nodod pieprasījumu instancei, kas jau darbojas ārpus nosaukumvietas, tāpēc parādās jauns logs, un datplūsma joprojām iziet caur tuneli. Dodiet tai atsevišķu profilu, lai jauna instance tiešām tiktu izveidota, pēc tam pārbaudiet procesa kontekstu, nevis miniet:

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

Abiem izvadiem jāsakrīt. Tā pati pārbaude darbojas jebkurai ilgstošai programmai, un to ir vērts veikt reizi katrā lietotnē, nevis pieņemt, ka palaidējs izdarīja to, ko jūs domājāt.

Vārdu atrisināšanai vajadzīgs savs lēmums. Nosaukumvietas izveide nedod tai resolvera konfigurāciju; faili katrai nosaukumvietai tiek atbalstīti caur /etc/netns/<name>/resolv.conf un bez tā jūs mantojat uzvedību, kuru ir viegli nepareizi nolasīt. IPv6 vajag tādu pašu attieksmi: ja nosaukumvietai nav v6 noklusējuma maršruta, kamēr lietotne dod priekšroku v6, pieprasījumi var iesprūst pirms atkāpšanās, kas izskatās kā salauzts tunelis.

Pārbaudiet ietvaru, ne tikai izejas adresi

Strādājoša publiskā adrese pierāda maršrutu, nevis visu prasību. Izejiet pārējo šādā secībā:

• ip netns exec clearnet ip route get 1.1.1.1 rāda veth noklusējuma maršrutu, nevis WireGuard saskarni.
• FORWARD skaitītāji abos noteikumos pieaug, kamēr notiek pieprasījums.
• Lietotnes process ziņo par gaidīto nosaukumvietas inode.
• Pēc pārstartēšanas nosaukumvieta pastāv pirms pakalpojuma sākuma; unit, kas darbojas agrāk, neizdodas vai, vēl ļaunāk, darbojas ārpus nosaukumvietas.

Pēc tam izlemiet, kam jānotiek, kad tunelis nokrīt. Nosaukumvieta turpina darboties, un tas ir vingrinājuma mērķis un arī risks: atbrīvotā programma paliek savienota, kamēr viss pārējais apstājas. Pierakstiet to kā politikas izvēli un esiet skaidri par to, ko atbrīvojums neaptver — konta identitāte, saglabātais pārlūkprogrammas stāvoklis un jūsu DNS nodrošinātājs visi atrodas ārpus tīkla nosaukumvietas darbības jomas, un atbrīvojuma uztveršana kā anonimitāte ir kļūda, kas pārdzīvo konfigurāciju.