Како да извршите еден Linux процес надвор од WireGuard тунел

Не можете да ослободите програма од WireGuard домаќин со целосен тунел со уредување на рутите. Рутите избираат пат по одредиште, а она што сакате да го ослободите е процес, па јадрото нема што да спореди. Изводливиот пристап е да му дадете на тој процес сопствен мрежен контекст: именски простор со сопствен интерфејс, адреси и стандардна рута, поврзан со домаќинот преку veth пар. Го извршив ова на Ubuntu 24.04 со wireguard-tools 1.0.20210914, и именскиот простор никогаш не беше проблемот — проблем беа политиката за проследување на домаќинот и правилата за означување на тунелот.

Прво изберете го видот на контекст што ви треба

Во практиката се појавуваат две форми. Ако домаќинот извршува целосен тунел и една програма треба да излезе по патот на ISP, градите втор именски простор, го поврзувате со домаќинот и му дозволувате на домаќинот да проследува и преведува сообраќај за него. Ако именскиот простор веќе носи VPN интерфејс и ви треба само наредба извршена внатре во него, тоа е вообичаениот ip netns exec случај и поголемиот дел од работата со рутирање е веќе завршен.

Ниту една од двете форми не ви дава правило ограничено на еден ID на процес. Netfilter споредува адреси, порти, ознаки и интерфејси; нема табела за рутирање по процес. Означувањето може да насочи сообраќај, но ознаката мора да се стави на пакети што веќе сте ги идентификувале, и тоа е истиот проблем едно ниво пониско. Именскиот простор го одделува целиот стек за тоа дрво на процеси, и затоа ова е вообичаениот одговор.

Ако барањето навистина е ништо да не излегува од тунелот, застанете го тунелот наместо тоа. Именскиот простор постои за мешаниот случај: една програма надвор, сѐ друго внатре, на истиот компјутер, во исто време.

Изградете го вториот контекст и поврзете го со домаќинот

Илустративен распоред: домаќинот има WireGuard интерфејс што ја носи стандардната рута и мрежен именски простор наречен clearnet поврзан со домаќинот преку veth пар. Адресите подолу се примери.

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

Овој именски простор сега може да го достигне домаќинот и ништо друго. Домаќинот мора да го проследи сообраќајот и да ја препише изворната адреса, бидејќи 192.168.100.0/24 е приватна и рутерот погоре нема рута назад во неа:

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

Потврдете ја страната на именскиот простор пред да продолжите.ip netns exec clearnet ip route треба да ја покаже veth рутата и стандардната рута преку 192.168.100.1, а ping до таа адреса треба да одговори. Ако ping до адресата на домаќинот не успее, адресите или состојбата на врската се погрешни и ниту едно правило на огнениот ѕид нема да помогне.

Кога имињата се решаваат, но ништо не се враќа, прочитајте FORWARD

Класичниот неуспех изгледа како грешка во рутирањето: именскиот простор решава име, пакетот излегува и никогаш не пристигнува одговор. На домаќини со FORWARD политика DROP — така прават неколку дистрибуции и повеќето зацврстени слики — пакетот се отфрла по патот, а грешката што ја печати програмата не кажува ништо за филтрирањето.

Прочитајте го синџирот пред да додадете нешто:

iptables -S FORWARD
nft list chain inet filter forward

Потоа пуштете го сообраќајот во двете насоки, со бројачи, за да знаете дали правилото некогаш се совпаднало:

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'

Правило со нула бројач на пакети не е на патот. Или имињата на интерфејсите се разликуваат од вашата претпоставка, или претходно правило во синџирот прво го прифатило, отфрлило или вратило пакетот. Поправете го редот, не текстот на правилото.

Одговорниот сообраќај е половината што луѓето ја забораваат. Правилото за враќање бара исто veth име плус совпаѓање на состојбата на врската, или едноставно прифаќање на интерфејсот ако ја држите политиката отворена. Додајте само излезното правило и првичниот симптом се враќа, додека вашето ново правило стои таму и изгледа исправно.

Држете ги правилата за означување на тунелот подалеку од новиот пат

Овој чекор го претвора работниот именски простор во таков што протекува. WireGuard поставките обично инсталираат политика за означување на огнениот ѕид заедно со свои правила за рутирање и посебна табела, така што неозначените пакети паѓаат назад во главната табела, додека означените ја користат табелата на тунелот. Проследениот сообраќај од именскиот простор се оценува спрема политичкото рутирање при излезот, и во зависност од тоа како се напишани тие правила, може да заврши во табелата на тунелот.

Два додатоци ги одделуваат патиштата. Вратете се рано во mangle синџирот за подмрежата на именскиот простор и додајте правило засновано на изворот што ја става таа подмрежа во главната табела:

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

Приоритетот 100 се подредува пред правилата на тунелот на мојот домаќин, па за тој извор одлучува обичната табела. Не го копирајте бројот слепо: приоритетите што wg-quick ги инсталира се разликуваат меѓу верзиите и меѓу поставките за IPv4 и IPv6, затоа извршете ip rule show и изберете приоритет што паѓа пред правилата на тунелот на вашата машина.

Проверете со пребарување специфично за изворот наместо да ѝ верувате на листата правила:

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

Ако првата наредба го пријави WireGuard интерфејсот, новото правило сѐ уште не е пред политиката на тунелот. Ако го пријави WAN интерфејсот додека втората сѐ уште ја покажува стандардната veth рута, домаќинот и именскиот простор не се согласуваат и треба да ги прочитате повторно двете табели за рутирање.

Стартувајте го процесот што ја отвора врската

Стартувањето на наредбата е еден ред, но стартувајте го процесот што навистина го создава сокетот.ip netns exec clearnet curl -s https://ifconfig.me е најмалиот чесен тест: го покажува адресата што именскиот простор му ја претставува на светот, не онаа што домаќинот би ја користел.

За услуга, прикачете го именскиот простор по пат за процесот да остане во него целиот свој живот:

[Service]
NetworkNamespacePath=/run/netns/clearnet

Графичките апликации се местото каде пристапот со еден ред тивко пропаѓа. Браузерот стартуван од мени често го предава барањето на примерок што веќе работи надвор од именскиот простор, па новиот прозорец се појавува, а сообраќајот сѐ уште излегува низ тунелот. Дајте му посебен профил за навистина да се создаде нов примерок, потоа проверете го контекстот на процесот наместо да погодувате:

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

Двата излеза мора да се совпаѓаат. Истата проверка работи за секоја долготрајна програма, и вреди да се направи еднаш по апликација наместо да се претпостави дека стартувачот го направил она што сте го мислеле.

Решавањето имиња бара своја одлука. Создавањето именски простор не му дава конфигурација на резолвер; датотеки по именски простор се поддржани преку /etc/netns/<name>/resolv.conf а без една наследувате однесување што лесно се чита погрешно. IPv6 бара исти третман: ако именскиот простор нема стандардна v6 рута додека апликацијата претпочита v6, барањата може да застанат пред да се повлечат, што изгледа како скршен тунел.

Проверете го рамката, не само излезната адреса

Работна јавна адреса докажува рута, не целото барање. Поминете го остатокот по овој ред:

• ip netns exec clearnet ip route get 1.1.1.1 ја покажува стандардната veth рута, не WireGuard интерфејсот.
• FORWARD бројачите на двете правила растат додека трае барањето.
• Процесот на апликацијата го пријавува inode на именскиот простор што го очекувате.
• По рестарт именскиот простор постои пред услугата да стартува; unit што работи порано не успева или, уште полошо, работи надвор од именскиот простор.

Потоа одлучете што треба да се случи кога тунелот паѓа. Именскиот простор продолжува да работи, што е целта на вежбата и истовремено ризикот: ослободената програма останува поврзана додека сѐ друго запира. Запишете го тоа како избор на политика и бидете јасни за тоа што ослободувањето не го покрива — идентитетот на сметката, зачуваната состојба на браузерот и вашиот DNS провајдер стојат сите надвор од опсегот на мрежен именски простор, а гледањето на ослободувањето како анонимност е грешката што ја надживува конфигурацијата.