Si të ekzekutoni një proces Linux jashtë një tuneli WireGuard

Nuk mund ta përjashtoni një program nga një host WireGuard me tunel të plotë duke redaktuar rrugët. Rrugët zgjedhin një shteg sipas destinacionit, dhe ajo që doni të përjashtoni është një proces, prandaj bërthama nuk ka me çfarë ta krahasojë. Qasja e zbatueshme është t'i jepni atij procesi kontekstin e vet të rrjetit: një hapësirë emrash me ndërfaqen, adresat dhe rrugën e paracaktuar të vet, e lidhur me hostin përmes një çifti veth. E ekzekutova këtë në Ubuntu 24.04 me wireguard-tools 1.0.20210914, dhe hapësira e emrave nuk ishte kurrë problemi — problemi ishin politika e përcjelljes së hostit dhe rregullat e shënjimit të tunelit.

Fillimisht zgjidhni llojin e kontekstit që ju nevojitet

Në praktikë shfaqen dy forma. Nëse hosti drejton një tunel të plotë dhe një program duhet të dalë nëpërmjet shtegut të ISP-së, ndërtoni një hapësirë të dytë emrash, e lidhni me hostin dhe lini hostin të përcjellë dhe të përkthejë trafikun për të. Nëse një hapësirë emrash tashmë mban një ndërfaqe VPN dhe ju nevojitet vetëm një komandë e nisur brenda saj, ky është rasti i zakonshëm i ip netns exec dhe pjesa më e madhe e punës së rrugëtimit është bërë tashmë.

Asnjëra formë nuk ju jep një rregull të kufizuar në një identifikues të vetëm procesi. Netfilter përputh adresa, porta, shenja dhe ndërfaqe; nuk ekziston një tabelë rrugëtimi për proces. Shënjimi mund të drejtojë trafikun, por shenja duhet të vendoset mbi paketa që i keni identifikuar tashmë, dhe ky është i njëjti problem një shtresë më poshtë. Një hapësirë emrash ndan të gjithë pirgun për atë pemë procesesh, dhe për këtë arsye është përgjigjja e zakonshme.

Nëse kërkesa është vërtet që asgjë të mos dalë nga tuneli, ndaloni tunelin. Hapësira e emrave ekziston për rastin e përzier: një program jashtë, gjithçka tjetër brenda, në të njëjtën makinë, në të njëjtën kohë.

Ndërtoni kontekstin e dytë dhe lidheni me hostin

Një plan ilustrues: hosti ka një ndërfaqe WireGuard që mban rrugën e paracaktuar, dhe një hapësirë emrash rrjeti të quajtur clearnet e lidhur me hostin përmes një çifti veth. Adresat më poshtë janë shembuj.

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

Kjo hapësirë emrash tani mund të arrijë hostin dhe asgjë tjetër. Hosti duhet të përcjellë trafikun dhe të rishkruajë adresën e burimit, sepse 192.168.100.0/24 është private dhe routeri i mësipërm nuk ka rrugë kthimi brenda saj:

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

Konfirmoni anën e hapësirës së emrave përpara se të vazhdoni.ip netns exec clearnet ip route duhet të tregojë rrugën veth dhe rrugën e paracaktuar përmes 192.168.100.1, dhe një ping drejt asaj adrese duhet të përgjigjet. Nëse ping-u drejt adresës së hostit dështon, adresat ose gjendja e lidhjes janë të gabuara dhe asnjë rregull firewalle nuk do të ndihmojë.

Kur emrat zgjidhen por asgjë nuk kthehet, lexoni FORWARD

Dështimi klasik duket si një gabim rrugëtimi: hapësira e emrave zgjidh një emër, paketa del dhe kurrë nuk arrin një përgjigje. Në hostet me politikë FORWARD të DROP-it — disa shpërndarje dhe shumica e imazheve të forcuara e bëjnë këtë — paketa hidhet gjatë rrugës, dhe gabimi që shtyp aplikacioni nuk thotë asgjë për filtrimin.

Lexoni zinxhirin përpara se të shtoni çdo gjë:

iptables -S FORWARD
nft list chain inet filter forward

Pastaj lejoni trafikun në të dy drejtimet, me numërues, që të mund të shihni nëse rregulli ka përputhur ndonjëherë:

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'

Një rregull me numërues zero paketash nuk është në shteg. Ose emrat e ndërfaqeve ndryshojnë nga ajo që supozuat, ose një rregull i mëparshëm në zinxhir e pranoi, e hodhi ose e ktheu paketën i pari. Rregulloni rendin, jo tekstin e rregullit.

Trafiku i përgjigjes është gjysma që njerëzit harrojnë. Rregulli i kthimit ka nevojë për të njëjtin emër veth plus një përputhje të gjendjes së lidhjes, ose një pranim të thjeshtë ndërfaqeje nëse e mbani politikën të hapur. Shtoni vetëm rregullin e daljes dhe simptoma fillestare kthehet, ndërsa rregulli juaj i ri qëndron atje dhe duket i saktë.

Mbani rregullat e shënjimit të tunelit larg shtegut të ri

Ky hap e kthen një hapësirë emrash që funksionon në një që rrjedh. Instalimet e WireGuard zakonisht instalojnë një politikë shenje firewalle bashkë me rregullat e tyre të rrugëtimit dhe një tabelë të dedikuar, kështu që paketat e pashënuara bien përsëri në tabelën kryesore, ndërsa ato të shënuara përdorin tabelën e tunelit. Trafiku i përcjellë nga hapësira e emrave vlerësohet kundrejt rrugëtimit me politikë në dalje dhe, në varësi të mënyrës se si janë shkruar ato rregulla, mund të përfundojë në tabelën e tunelit.

Dy shtesa i ndajnë shtigjet. Kthehuni herët në zinxhirin mangle për nënrrjetin e hapësirës së emrave dhe shtoni një rregull të bazuar në burim që e vendos atë nënrrjet në tabelën kryesore:

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

Përparësia 100 renditet përpara rregullave të tunelit në hostin tim, kështu që për atë burim vendos tabela e zakonshme. Mos e kopjoni numrin verbërisht: përparësitë që wg-quick instalon ndryshojnë midis versioneve dhe midis konfigurimeve IPv4 dhe IPv6, prandaj ekzekutoni ip rule show dhe zgjidhni një përparësi që bie përpara rregullave të tunelit në makinën tuaj.

Verifikoni me një kërkim specifik për burimin në vend që t'i besoni listës së rregullave:

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

Nëse komanda e parë raporton ndërfaqen WireGuard, rregulli i ri nuk është ende përpara politikës së tunelit. Nëse raporton ndërfaqen WAN ndërsa e dyta ende tregon rrugën e paracaktuar veth, hosti dhe hapësira e emrave nuk janë dakord dhe duhet t'i lexoni përsëri të dyja tabelat e rrugëtimit.

Nisni procesin që hap lidhjen

Nisja e komandës është një rresht, por nisni procesin që krijon vërtet socket-in.ip netns exec clearnet curl -s https://ifconfig.me është testi i ndershëm më i vogël: tregon adresën që hapësira e emrave i paraqet botës, jo atë që hosti do të përdorte.

Për një shërbim, lidhni hapësirën e emrave sipas shtegut që procesi të mbetet në të gjithë jetën:

[Service]
NetworkNamespacePath=/run/netns/clearnet

Aplikacionet grafike janë vendi ku qasja me një rresht dështon në heshtje. Një shfletues i nisur nga një menu shpesh ia dorëzon kërkesën një shembulli që tashmë punon jashtë hapësirës së emrave, kështu që dritarja e re shfaqet dhe trafiku ende del nga tuneli. Jepini një profil të veçantë që një shembull i ri të krijohet vërtet, pastaj kontrolloni kontekstin e procesit në vend që të hamendësoni:

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

Dy daljet duhet të përputhen. I njëjti kontroll funksionon për çdo program afatgjatë, dhe ia vlen të bëhet një herë për aplikacion në vend që të supozohet se nisësi bëri atë që kishit ndërmend.

Zgjidhja e emrave kërkon vendimin e vet. Krijimi i një hapësire emrash nuk i jep konfigurim të zgjidhësit; skedarët për hapësirë emrash mbështeten përmes /etc/netns/<name>/resolv.conf dhe pa një të tillë trashëgoni sjellje që lexohet lehtë gabimisht. IPv6 kërkon të njëjtin trajtim: nëse hapësira e emrave nuk ka rrugë të paracaktuar v6 ndërsa aplikacioni preferon v6, kërkesat mund të ngecin përpara se të tërhiqen, gjë që duket si një tunel i prishur.

Kontrolloni kornizën, jo vetëm adresën e daljes

Një adresë publike që funksionon dëshmon rrugën, jo të gjithë kërkesën. Kaloni pjesën tjetër në këtë rend:

• ip netns exec clearnet ip route get 1.1.1.1 tregon rrugën e paracaktuar veth, jo ndërfaqen WireGuard.
• Numëruesit FORWARD në të dy rregullat rriten ndërsa një kërkesë punon.
• Procesi i aplikacionit raporton inode-in e hapësirës së emrave që prisni.
• Pas një rindezjeje hapësira e emrave ekziston përpara se shërbimi të nisë; një unit që punon më herët dështon ose, më keq, punon jashtë hapësirës së emrave.

Pastaj vendosni çfarë duhet të ndodhë kur tuneli bie. Hapësira e emrave vazhdon të punojë, që është qëllimi i ushtrimit dhe njëkohësisht rreziku: programi i përjashtuar mbetet i lidhur ndërsa çdo gjë tjetër ndalet. Regjistroni këtë si zgjedhje politike dhe jini të qartë për atë që përjashtimi nuk mbulon — identiteti i llogarisë, gjendja e ruajtur e shfletuesit dhe ofruesi juaj i DNS-së qëndrojnë të gjitha jashtë sferës së një hapësire emrash rrjeti, dhe trajtimi i përjashtimit si anonimitet është gabimi që i mbijeton konfigurimit.