Egy Linux-folyamat futtatása WireGuard-alagúton kívül

Nem tud egy programot kivonni egy teljes alagutat futtató WireGuard-gazda alól az útvonalak szerkesztésével. Az útvonalak a céltól függően választanak utat, és amit ki akar vonni, az egy folyamat, így a kernelnek nincs mihez illesztenie. A járható megközelítés az, hogy ennek a folyamatnak saját hálózati környezetet ad: egy névtér, saját interfésszel, címekkel és alapértelmezett útvonallal, amelyet veth-pár köt össze a gazdával. Ubuntu 24.04-en futtattam wireguard-tools 1.0.20210914-gyel, és a névtér soha nem volt a probléma — a gazda továbbítási házirendje és az alagút jelölési szabályai voltak azok.

Először válassza ki a szükséges környezet típusát

A gyakorlatban két forma fordul elő. Ha a gazda teljes alagutat futtat, és egy programnak az ISP útvonalán kell kijutnia, épít egy második névteret, összeköti a gazdával, és hagyja, hogy a gazda továbbítsa és lefordítsa számára a forgalmat. Ha egy névtér már hordoz VPN-interfészt, és csak egy benne indított parancsra van szüksége, az a szokásos ip netns exec eset, és az útválasztási munka nagy része már kész.

Egyik forma sem ad olyan szabályt, amely egyetlen folyamatazonosítóra korlátozódik. A Netfilter címeket, portokat, jelöléseket és interfészeket illeszt; folyamatonkénti útválasztási tábla nincs. A jelölés irányíthatja a forgalmat, de a jelölést olyan csomagokra kell tenni, amelyeket már azonosított, és ez ugyanaz a probléma egy szinttel lejjebb. A névtér az egész vermet elválasztja ehhez a folyamatfához, és ezért ez a szokásos válasz.

Ha a követelmény valóban az, hogy semmi ne hagyja el az alagutat, inkább állítsa le az alagutat. A névtér a vegyes esetre létezik: egy program kifelé, minden más befelé, ugyanazon a gépen, ugyanabban az időben.

Építse fel a második környezetet, és kösse össze a gazdával

Szemléltető elrendezés: a gazdának van egy WireGuard-interfésze, amely az alapértelmezett útvonalat hordozza, és egy clearnet nevű hálózati névtér, amelyet veth-pár köt össze a gazdával. Az alábbi címek példák.

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

Ez a névtér most eléri a gazdát, és semmi mást. A gazdának továbbítania kell a forgalmat, és át kell írnia a forráscímet, mert a 192.168.100.0/24 privát, és a felsőbb routernek nincs visszaútvonala bele:

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

A továbblépés előtt ellenőrizze a névtér oldalát.ip netns exec clearnet ip route ki kellene írnia a veth-útvonalat és az alapértelmezett útvonalat a 192.168.100.1 felé, és a pingnek erre a címre válaszolnia kellene. Ha a gazda címére küldött ping sikertelen, a címek vagy a kapcsolat állapota hibás, és semmilyen tűzfalszabály nem segít.

Ha a nevek feloldódnak, de semmi nem jön vissza, olvassa el a FORWARD-ot

A klasszikus hiba útválasztási bugnak látszik: a névtér felold egy nevet, a csomag kimegy, és soha nem érkezik válasz. Azokon a gazdákon, ahol a FORWARD házirend DROP — több disztribúció és a legtöbb megerősített kép ezt teszi — a csomag útközben eldobódik, és az alkalmazás által kiírt hiba semmit sem mond a szűrésről.

Olvassa el a láncot, mielőtt bármit hozzáadna:

iptables -S FORWARD
nft list chain inet filter forward

Ezután engedje át a forgalmat mindkét irányban, számlálókkal, hogy lássa, illeszkedett-e valaha a szabály:

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'

A nulla csomagszámlálójú szabály nincs az útvonalon. Vagy eltérnek az interfésznevek attól, amit feltételezett, vagy a lánc egy korábbi szabálya fogadta el, dobta el vagy küldte vissza elsőként a csomagot. A sorrendet javítsa, ne a szabály szövegét.

A válaszforgalom az a fél, amelyet az emberek elfelejtenek. A visszatérési szabálynak ugyanaz a veth-név kell, plusz kapcsolatállapot-egyezés, vagy egyszerű interfész-elfogadás, ha nyitva tartja a házirendet. Csak a kimenő szabályt adja hozzá, és az eredeti tünet visszatér, miközben az új szabály ott áll és helyesnek látszik.

Tartsa távol az alagút jelölési szabályait az új útvonaltól

Ez a lépés működő névteret szivárgóvá tesz. A WireGuard-telepítések általában tűzfal-jelölési házirendet telepítenek saját útválasztási szabályaikkal és egy dedikált táblával, így a jelöletlen csomagok visszaesnek a fő táblára, míg a jelölt csomagok az alagút tábláját használják. A névtérből továbbított forgalmat kifelé menet a házirend-alapú útválasztás alapján értékelik, és attól függően, hogyan írták ezeket a szabályokat, az alagút táblájába kerülhet.

Két kiegészítés választja szét az útvonalakat. Térjen vissza korán a mangle-láncban a névtér alhálózatához, és adjon hozzá egy forrásalapú szabályt, amely ezt az alhálózatot a fő táblába teszi:

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

A 100-as prioritás a gazdámon az alagút szabályai elé kerül, így ennél a forrásnál a szokásos tábla dönt. Ne másolja a számot vakon: azokat a prioritásokat, amelyeket wg-quick telepít, eltérnek a verziók és az IPv4-, illetve IPv6-beállítások között, ezért futtassa a ip rule show parancsot, és válasszon olyan prioritást, amely a gépén az alagút szabályai elé esik.

Ellenőrizze forrásspecifikus kereséssel a szabálylista megbízása helyett:

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

Ha az első parancs a WireGuard-interfészt jelenti, az új szabály még nem került az alagút házirendje elé. Ha a WAN-interfészt jelenti, miközben a második még a veth alapértelmezett útvonalat mutatja, a gazda és a névtér nem egyeznek, és újra kell olvasnia mindkét útválasztási táblát.

Indítsa el azt a folyamatot, amely megnyitja a kapcsolatot

A parancs elindítása egy sor, de azt a folyamatot indítsa el, amely valóban létrehozza a socketet.ip netns exec clearnet curl -s https://ifconfig.me a legkisebb őszinte teszt: azt a címet mutatja, amelyet a névtér a világ felé képvisel, nem azt, amelyet a gazda használna.

Szolgáltatás esetén útvonal alapján csatolja a névteret, hogy a folyamat egész életében benne maradjon:

[Service]
NetworkNamespacePath=/run/netns/clearnet

A grafikus alkalmazások azok, ahol az egysoros megközelítés csendesen elbukik. A menüből indított böngésző gyakran egy már a névtéren kívül futó példánynak adja át a kérést, így az új ablak megjelenik, és a forgalom továbbra is az alagúton megy ki. Adjon neki külön profilt, hogy valóban új példány jöjjön létre, majd a találgatás helyett ellenőrizze a folyamat környezetét:

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

A két kimenetnek egyeznie kell. Ugyanez az ellenőrzés működik minden hosszan futó programnál, és érdemes alkalmazásonként egyszer elvégezni, ahelyett hogy feltételezné, az indító azt tette, amit szeretett volna.

A névfeloldás saját döntést igényel. Egy névtér létrehozása nem ad neki feloldó konfigurációt; a névtérenkénti fájlokat a /etc/netns/<name>/resolv.conf támogatja, és enélkül olyan viselkedést örököl, amelyet könnyű félreolvasni. Az IPv6 ugyanezt a kezelést igényli: ha a névtérnek nincs v6-os alapértelmezett útvonala, miközben az alkalmazás a v6-ot részesíti előnyben, a kérések megakadhatnak a visszaesés előtt, ami törött alagútnak látszik.

Ellenőrizze a keretezést, ne csak a kilépési címet

Egy működő nyilvános cím az útvonalat bizonyítja, nem a teljes követelményt. A többit ebben a sorrendben járja végig:

• ip netns exec clearnet ip route get 1.1.1.1 a veth alapértelmezett útvonalat mutatja, nem a WireGuard-interfészt.
• Mindkét szabály FORWARD-számlálója nő, miközben egy kérés fut.
• Az alkalmazás folyamata a várt névtér-inode-ot jelenti.
• Újraindítás után a névtér létezik, mielőtt a szolgáltatás elindul; egy korábban futó unit elbukik, vagy ami rosszabb, a névtéren kívül fut.

Ezután döntse el, mi történjen, amikor az alagút leesik. A névtér tovább működik, ami a gyakorlat lényege és egyben a kockázat: a kivont program kapcsolva marad, miközben minden más leáll. Rögzítse ezt házirend-döntésként, és legyen világos azzal kapcsolatban, mit nem fed le a kivétel — a fiókidentitás, a mentett böngészőállapot és a DNS-szolgáltató mind a hálózati névtér hatókörén kívül esik, és a kivételt anonimitásként kezelni az a hiba, amely túléli a konfigurációt.