Како покренути један 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 провајдер стоје сви изван опсега мрежног именског простора, а третирање изузећа као анонимности је грешка која надживљава конфигурацију.