Program z hostiteľa WireGuard s plným tunelom nevyjmete úpravou trás. Trasy vyberajú cestu podľa cieľa, a to, čo chcete vyňať, je proces, takže jadro nemá čo porovnávať. Schodná cesta je dať tomu procesu vlastný sieťový kontext: menný priestor s vlastným rozhraním, adresami a predvolenou trasou, prepojený s hostiteľom párom veth. Spustil som to na Ubuntu 24.04 s wireguard-tools 1.0.20210914 a menný priestor nikdy nebol problém — problémom boli politika presmerovania hostiteľa a pravidlá označovania tunela.

Najprv si vyberte druh kontextu, ktorý potrebujete

V praxi sa objavujú dve formy. Ak hostiteľ prevádzkuje plný tunel a jeden program má odísť cestou ISP, postavíte druhý menný priestor, pripojíte ho k hostiteľovi a necháte hostiteľa, aby zaň presmerúval a prekladal prevádzku. Ak už menný priestor nesie rozhranie VPN a potrebujete len príkaz spustený v ňom, je to obvyklý prípad ip netns exec a väčšina práce s trasami je už hotová.

Ani jedna forma vám nedá pravidlo obmedzené na jedno ID procesu. Netfilter porovnáva adresy, porty, značky a rozhrania; tabuľka trás na proces neexistuje. Označovanie môže usmerniť prevádzku, ale značka sa musí aplikovať na pakety, ktoré ste už identifikovali, a to je ten istý problém o vrstvu nižšie. Menný priestor oddeľuje celý zásobník pre ten strom procesov, a preto je to obvyklá odpoveď.

Ak je požiadavka skutočne taká, že z tunela nič nevyjde, radšej tunel zastavte. Menný priestor existuje pre zmiešaný prípad: jeden program von, všetko ostatné dnu, na tom istom stroji, v tom istom čase.

Postavte druhý kontext a pripojte ho k hostiteľovi

Ilustratívne usporiadanie: hostiteľ má rozhranie WireGuard nesúce predvolenú trasu a sieťový menný priestor nazvaný clearnet prepojený s hostiteľom párom veth. Adresy nižšie sú príklady.

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

Tento menný priestor teraz dosiahne hostiteľa a nič iné. Hostiteľ musí presmerúvať prevádzku a prepisovať zdrojovú adresu, pretože 192.168.100.0/24 je súkromná a nadradený router nemá cestu späť do nej:

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

Predtým, ako budete pokračovať, overte stranu menného priestoru.ip netns exec clearnet ip route by malo ukázať trasu veth a predvolenú trasu cez 192.168.100.1 a ping na túto adresu by mal odpovedať. Ak ping na adresu hostiteľa zlyhá, adresy alebo stav spojenia sú nesprávne a žiadne pravidlo firewallu nepomôže.

Keď sa mená prekladajú, ale nič sa nevracia, prečítajte FORWARD

Klasické zlyhanie vyzerá ako chyba smerovania: menný priestor preloží meno, paket odíde a odpoveď nikdy nepríde. Na hostiteľoch s politikou FORWARD DROP — tak to robí niekoľko distribúcií a väčšina spevnených obrazov — sa paket cestou zahodí a chyba, ktorú aplikácia vypíše, o filtrovaní nič nehovorí.

Prečítajte reťazec, skôr než čokoľvek pridáte:

iptables -S FORWARD
nft list chain inet filter forward

Potom pustite prevádzku v oboch smeroch, s počítadlami, aby ste poznali, či pravidlo niekedy zodpovedalo:

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'

Pravidlo s nulovým počítadlom paketov nie je na ceste. Buď sa názvy rozhraní odlišujú od predpokladu, alebo skoršie pravidlo v reťazci paket prijalo, zahodilo či vrátilo ako prvé. Opravte poradie, nie text pravidla.

Odchádzajúca odpoveď je polovica, na ktorú sa zabúda. Pravidlo návratu potrebuje rovnaký názov veth plus zhodu stavu spojenia, alebo obyčajné prijatie rozhrania, ak politiku držíte otvorenú. Pridajte iba pravidlo odchodu a pôvodný príznak sa vráti, pričom vaše nové pravidlo tam stojí a vyzerá správne.

Držte pravidlá označovania tunela mimo novej cesty

Tento krok premení fungujúci menný priestor na presakujúci. Inštalácie WireGuard zvyčajne nainštalujú politiku značky firewallu spolu s vlastnými pravidlami smerovania a vyhradenou tabuľkou, takže neoznačené pakety padajú späť do hlavnej tabuľky, kým označené používajú tabuľku tunela. Presmerovaná prevádzka z menného priestoru sa pri odchode vyhodnocuje proti politickému smerovaniu a podľa toho, ako boli tieto pravidlá napísané, môže skončiť v tabuľke tunela.

Dve doplnenia oddeľujú cesty. Vráťte sa skoro v reťazci mangle pre podsiet menného priestoru a pridajte pravidlo založené na zdroji, ktoré túto podsiet umiestni do hlavnej tabuľky:

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

Priorita 100 sa na mojom hostiteľovi radí pred pravidlami tunela, takže pre tento zdroj rozhoduje bežná tabuľka. Nekopírujte číslo naslepo: priority, ktoré wg-quick inštaluje, sa líšia medzi verziami a medzi nastaveniami IPv4 a IPv6, preto spustite ip rule show a vyberte prioritu, ktorá na vašom stroji padne pred pravidlá tunela.

Overte pomocou vyhľadania špecifického pre zdroj namiesto spoliehania sa na zoznam pravidiel:

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

Ak prvý príkaz hlási rozhranie WireGuard, nové pravidlo ešte nie je pred politikou tunela. Ak hlási rozhranie WAN, kým druhý stále ukazuje predvolenú trasu veth, hostiteľ a menný priestor sa nezhodujú a mali by ste obidve tabuľky trás prečítať znova.

Spustite proces, ktorý otvára spojenie

Spustiť príkaz je jeden riadok, ale spustite proces, ktorý skutočne vytvára socket.ip netns exec clearnet curl -s https://ifconfig.me je najmenší čestný test: ukazuje adresu, ktorú menný priestor predstavuje svetu, nie tú, ktorú by použil hostiteľ.

Pre službu pripojte menný priestor cestou, aby v ňom proces zostal celý život:

[Service]
NetworkNamespacePath=/run/netns/clearnet

Grafické aplikácie sú miestom, kde jednoriadkový prístup ticho zlyháva. Prehliadač spustený z ponuky často odovzdá požiadavku inštancii, ktorá už beží mimo menného priestoru, takže sa objaví nové okno a prevádzka stále odchádza tunelom. Dajte mu samostatný profil, aby sa naozaj vytvorila nová inštancia, a potom skontrolujte kontext procesu namiesto hádania:

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

Oba výstupy sa musia zhodovať. Rovnaká kontrola funguje pre každý dlho bežiaci program a stojí za to urobiť ju raz na aplikáciu namiesto predpokladu, že spúšťač urobil, čo ste mysleli.

Preklad mien potrebuje vlastné rozhodnutie. Vytvorenie menného priestoru mu nedá konfiguráciu resolvera; súbory pre jednotlivé menné priestory sú podporované cez /etc/netns/<name>/resolv.conf a bez neho zdedíte správanie, ktoré sa dá ľahko prečítať nesprávne. IPv6 potrebuje rovnaké zaobchádzanie: ak menný priestor nemá predvolenú trasu v6, kým aplikácia uprednostňuje v6, požiadavky sa môžu zaseknúť pred návratom, čo vyzerá ako pokazený tunel.

Skontrolujte rámovanie, nie len výstupnú adresu

Fungujúca verejná adresa dokazuje trasu, nie celú požiadavku. Prejdite zvyšok v tomto poradí:

  • ip netns exec clearnet ip route get 1.1.1.1 ukazuje predvolenú trasu veth, nie rozhranie WireGuard.
  • Počítadlá FORWARD na oboch pravidlách rastú, kým požiadavka beží.
  • Proces aplikácie hlási inode menného priestoru, ktorý očakávate.
  • Po reštarte menný priestor existuje skôr, než služba začne; unit, ktorý beží skôr, zlyhá alebo, čo je horšie, beží mimo menného priestoru.

Potom rozhodnite, čo sa má stať, keď tunel padne. Menný priestor funguje ďalej, čo je zmyslom cvičenia a zároveň rizikom: vyňatý program zostáva pripojený, kým sa všetko ostatné zastaví. Zapíšte to ako rozhodnutie politiky a buďte jasní v tom, čo výnimka nepokrýva — identita účtu, uložený stav prehliadača a váš poskytovateľ DNS stoja všetky mimo rozsahu sieťového menného priestoru, a považovať výnimku za anonymitu je chyba, ktorá prežije konfiguráciu.

Súvisiace články