Näin ajat yhden Linux-prosessin WireGuard-tunnelin ulkopuolella

Et voi vapauttaa ohjelmaa täystunnelia käyttävältä WireGuard-isännältä reittejä muokkaamalla. Reitit valitsevat polun kohteen mukaan, ja vapautettava asia on prosessi, joten ytimellä ei ole mitään sovitettavaa. Toimiva lähestymistapa on antaa sille prosessille oma verkkokonteksti: nimiavaruus, jolla on oma liitäntänsä, osoitteensa ja oletusreittinsä ja joka on yhdistetty isäntään veth-parilla. Ajoin tämän Ubuntu 24.04:ssä wireguard-tools 1.0.20210914:n kanssa, eikä nimiavaruus ollut koskaan ongelma — ongelma olivat isännän välityskäytäntö ja tunnelin merkintäsäännöt.

Valitse ensin tarvitsemasi kontekstityyppi

Käytännössä esiintyy kaksi muotoa. Jos isäntä ajaa täystunnelia ja yhden ohjelman pitää poistua ISP:n polkua pitkin, rakennat toisen nimiavaruuden, yhdistät sen isäntään ja annat isännän välittää ja kääntää liikenne sen puolesta. Jos nimiavaruudella on jo VPN-liitäntä ja tarvitset vain sen sisällä käynnistettävän komennon, kyseessä on tavallinen ip netns exec tapaus ja suurin osa reititystyöstä on jo tehty.

Kumpikaan muoto ei anna sinulle sääntöä, joka rajautuu yhteen prosessitunnukseen. Netfilter sovittaa osoitteita, portteja, merkintöjä ja liitäntöjä; reititystaulua prosessia kohden ei ole. Merkintä voi ohjata liikennettä, mutta merkintä täytyy asettaa paketteihin, jotka olet jo tunnistanut, ja se on sama ongelma kerrosta alempana. Nimiavaruus erottaa koko pinon kyseiselle prosessipuulle, ja siksi se on tavallinen vastaus.

Jos vaatimus on todella, että tunnelista ei poistu mitään, pysäytä sen sijaan tunneli. Nimiavaruus on sekamuotoa varten: yksi ohjelma ulos, kaikki muu sisään, samalla koneella, samaan aikaan.

Rakenna toinen konteksti ja yhdistä se isäntään

Havainnollistava asettelu: isännällä on WireGuard-liitäntä, joka kantaa oletusreitin, ja verkkonimiavaruus nimeltä clearnet joka on yhdistetty isäntään veth-parilla. Alla olevat osoitteet ovat esimerkkejä.

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

Tämä nimiavaruus voi nyt tavoittaa isännän eikä mitään muuta. Isännän täytyy välittää liikenne ja kirjoittaa lähdeosoite uudelleen, koska 192.168.100.0/24 on yksityinen eikä ylemmällä reitittimellä ole reittiä takaisin siihen:

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

Varmista nimiavaruuden puoli ennen jatkamista.ip netns exec clearnet ip route pitäisi näyttää veth-reitti ja oletusreitti osoitteen 192.168.100.1 kautta, ja pingin siihen osoitteeseen pitäisi vastata. Jos ping isännän osoitteeseen epäonnistuu, osoitteet tai linkin tila ovat väärin, eikä mikään palomuurisääntö auta.

Kun nimet ratkeavat mutta mitään ei tule takaisin, lue FORWARD

Klassinen vika näyttää reititysbugilta: nimiavaruus ratkaisee nimen, paketti lähtee eikä vastausta koskaan tule. Isännillä, joilla FORWARD-käytäntö on DROP — niin tekevät useat jakelut ja useimmat koventnetut levykuvat — paketti pudotetaan matkalla, eikä sovelluksen tulostama virhe kerro suodatuksesta mitään.

Lue ketju ennen kuin lisäät mitään:

iptables -S FORWARD
nft list chain inet filter forward

Päästä sitten liikenne läpi molempiin suuntiin laskureiden kanssa, jotta näet, osuiko sääntö koskaan:

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'

Sääntö, jonka pakettilaskuri on nolla, ei ole polulla. Joko liitäntöjen nimet poikkeavat oletuksestasi tai aiempi sääntö ketjussa hyväksyi, pudotti tai palautti paketin ensin. Korjaa järjestys, älä säännön tekstiä.

Vastausliikenne on se puoli, joka unohdetaan. Paluusääntö tarvitsee saman veth-nimen sekä yhteyden tilan sovituksen tai tavallisen liitännän hyväksynnän, jos pidät käytännön avoimena. Lisää vain lähtevä sääntö, ja alkuperäinen oire palaa, kun uusi sääntösi seisoo siinä ja näyttää oikealta.

Pidä tunnelin merkintäsäännöt poissa uudelta polulta

Tämä vaihe muuttaa toimivan nimiavaruuden vuotavaksi. WireGuard-asennukset asentavat yleensä palomuurimerkinnän käytännön sekä omat reitityssääntönsä ja oman taulunsa, joten merkitsemättömät paketit putoavat päätauluun ja merkityt käyttävät tunnelin taulua. Nimiavaruudesta välitetty liikenne arvioidaan lähtiessään käytäntöperusteista reititystä vasten, ja riippuen siitä, miten nämä säännöt on kirjoitettu, se voi päätyä tunnelin tauluun.

Kaksi lisäystä erottaa polut. Palaa aikaisin mangle-ketjussa nimiavaruuden aliverkolle ja lisää lähdeperusteinen sääntö, joka laittaa aliverkon päätauluun:

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

Prioriteetti 100 järjestyy isännälläni tunnelin sääntöjen edelle, joten kyseisen lähteen osalta tavallinen taulu päättää. Älä kopioi numeroa sokeasti: prioriteetit, jotka wg-quick asentaa, eroavat versioiden ja IPv4- sekä IPv6-asennusten välillä, joten aja ip rule show ja valitse prioriteetti, joka osuu koneellasi tunnelin sääntöjen edelle.

Tarkista lähdekohtaisella haulla sen sijaan, että luottaisit sääntöluetteloon:

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

Jos ensimmäinen komento raportoi WireGuard-liitännän, uusi sääntö ei ole vielä tunnelin käytännön edellä. Jos se raportoi WAN-liitännän, kun toinen näyttää yhä veth-oletusreitin, isäntä ja nimiavaruus ovat eri mieltä, ja sinun kannattaa lukea molemmat reititystaulut uudelleen.

Käynnistä prosessi, joka avaa yhteyden

Komennon käynnistäminen on yksi rivi, mutta käynnistä prosessi, joka todella luo pistokkeen.ip netns exec clearnet curl -s https://ifconfig.me on pienin rehellinen testi: se näyttää osoitteen, jonka nimiavaruus esittää maailmalle, ei sitä, jota isäntä käyttäisi.

Palvelun kohdalla liitä nimiavaruus polun kautta, jotta prosessi pysyy siinä koko elinikänsä:

[Service]
NetworkNamespacePath=/run/netns/clearnet

Graafiset sovellukset ovat paikka, jossa yhden rivin lähestymistapa epäonnistuu hiljaa. Valikosta käynnistetty selain antaa pyynnön usein instanssille, joka on jo käynnissä nimiavaruuden ulkopuolella, joten uusi ikkuna ilmestyy ja liikenne lähtee edelleen tunnelin kautta. Anna sille erillinen profiili, jotta uusi instanssi todella luodaan, ja tarkista sitten prosessin konteksti arvaamisen sijaan:

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

Kahden tulosteen on täsmättävä. Sama tarkistus toimii mille tahansa pitkäikäiselle ohjelmalle, ja se kannattaa tehdä kerran sovellusta kohden sen sijaan, että olettaisi käynnistimen tekevän sen, mitä tarkoitit.

Nimien selvitys tarvitsee oman päätöksensä. Nimiavaruuden luominen ei anna sille resolverin asetuksia; nimiavaruuskohtaisia tiedostoja tuetaan /etc/netns/<name>/resolv.conf kautta, ja ilman sitä perit käyttäytymisen, joka on helppo lukea väärin. IPv6 tarvitsee saman kohtelun: jos nimiavaruudella ei ole v6-oletusreittiä, kun sovellus suosii v6:tä, pyynnöt voivat juuttua ennen perääntymistä, mikä näyttää rikkinäiseltä tunnelilta.

Tarkista kehys, ei vain lähtöosoitetta

Toimiva julkinen osoite todistaa reitin, ei koko vaatimusta. Käy loput läpi tässä järjestyksessä:

• ip netns exec clearnet ip route get 1.1.1.1 näyttää veth-oletusreitin, ei WireGuard-liitäntää.
• Molempien sääntöjen FORWARD-laskurit kasvavat, kun pyyntö on käynnissä.
• Sovellusprosessi raportoi odottamasi nimiavaruuden inoden.
• Uudelleenkäynnistyksen jälkeen nimiavaruus on olemassa ennen palvelun alkua; aiemmin ajettava unit epäonnistuu tai, pahempaa, ajaa nimiavaruuden ulkopuolella.

Päätä sitten, mitä pitäisi tapahtua, kun tunneli putoaa. Nimiavaruus jatkaa toimintaansa, mikä on harjoituksen tarkoitus ja samalla riski: vapautettu ohjelma pysyy yhteydessä, kun kaikki muu pysähtyy. Kirjaa se käytäntövalintana ja ole selvä siitä, mitä vapautus ei kata — tilin identiteetti, tallennettu selaimen tila ja DNS-tarjoajasi ovat kaikki verkkonimiavaruuden ulottumattomissa, ja vapautuksen pitäminen anonymiteettinä on se virhe, joka elää asetuksia pidempään.