Hoe kinne jo ien Linux-proses bûten in WireGuard-tunnel draaie

Jo kinne in programma net fan in WireGuard-host mei folsleine tunnel útslute troch rûtes te bewurkjen. Rûtes kieze in paad op basis fan bestimming, en wat jo útslute wolle is in proses, dus de kernel hat neat om op te passen. De wurkbere oanpak is om dat proses syn eigen netwurk-kontekst te jaan: in nammeromte mei syn eigen ynterface, adressen en standertrûte, ferbûn mei de host troch in veth-pear. Ik haw dit draaid op Ubuntu 24.04 mei wireguard-tools 1.0.20210914, en de nammeromte wie nea it probleem — it trochstjoerbelied fan de host en de markearringsregels fan de tunnel wiene dat.

Kies earst it soarte kontekst dat jo nedich hawwe

Yn 'e praktyk komme twa foarmen foar. As de host in folsleine tunnel draait en ien programma moat fia it ISP-paad nei bûten, bouwe jo in twadde nammeromte, ferbine dy mei de host en litte de host it ferkear foar dy trochstjoere en oersette. As in nammeromte al in VPN-ynterface hat en jo allinich in opdracht nedich hawwe dy't deryn start wurdt, dan is dat it gewoane ip netns exec gefal en it measte fan it rûtewurk is al dien.

Gjin fan beide foarmen jout jo in regel dy't beheind is ta ien proses-ID. Netfilter past adressen, poarten, marken en ynterfaces oan; der is gjin rûtetabel per proses. Markearring kin ferkear stjoere, mar de marke moat op pakketten set wurde dy't jo al identifisearre hawwe, en dat is itselde probleem ien laach leger. In nammeromte skiedt de hiele stapel foar dat prosesbeam, en dêrom is it it gewoane antwurd.

As de eask echt is dat der neat út 'e tunnel giet, stopje dan de tunnel. De nammeromte bestiet foar it mingde gefal: ien programma út, al it oare yn, op deselde masine, op itselde stuit.

Bou de twadde kontekst en ferbine dy mei de host

In yllustrative yndieling: de host hat in WireGuard-ynterface dy't de standertrûte draacht, en in netwurk-nammeromte neamd clearnet ferbûn mei de host troch in veth-pear. De adressen hjirûnder binne foarbylden.

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

Dy nammeromte kin no de host berikke en neat oars. De host moat it ferkear trochstjoere en it boarneadres oerskriuwe, want 192.168.100.0/24 is partikulier en de upstream-router hat gjin rûte werom deryn:

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

Befêstigje de kant fan de nammeromte foardat jo fierder geane.ip netns exec clearnet ip route soe de veth-rûte en de standertrûte fia 192.168.100.1 sjen litte, en in ping nei dat adres soe antwurdzje moatte. As in ping nei it adres fan de host mislearret, binne de adressen of de steat fan 'e keppeling ferkeard en gjin firewallregel sil helpe.

As nammen oplosse mar der komt neat werom, lês dan FORWARD

De klassike flater liket op in rûte-bug: de nammeromte lost in namme op, it pakket giet nei bûten en der komt nea in antwurd. Op hosts mei in FORWARD-belied fan DROP — ferskate distribúsjes en de measte hurdere bylden dogge dat — wurdt it pakket ûnderweis weilitten, en de flater dy't it programma printsje lit, seit neat oer filterjen.

Lês de keatling foardat jo eat tafoegje:

iptables -S FORWARD
nft list chain inet filter forward

Lit it ferkear dan yn beide rjochtingen troch, mei tellers, sadat jo sjen kinne oft de regel ea oerienkommen is:

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'

In regel mei in nulpakketteller is net yn it paad. Of de ynterfacenammen ferskille fan wat jo oannommen, of in eardere regel yn 'e keatling hat it pakket earst akseptearre, weilitten of weromjûn. Reparearje de folchoarder, net de tekst fan 'e regel.

Antwurdferkear is de helte dy't minsken ferjitte. De weromregel hat deselde veth-namme nedich plus in oerienkomst fan ferbiningsteat, of in gewoane ynterface-akseptaasje as jo it belied iepen hâlde. Foegje allinich de útgeande regel ta en it oarspronklike symptoom komt werom, mei jo nije regel dêr en hy liket korrekt.

Hâld de markearringsregels fan 'e tunnel fuort fan it nije paad

Dizze stap makket fan in wurkjende nammeromte ien dy't lekt. WireGuard-opsjes ynstallearje meastentiids in firewallmarkbelied plus har eigen rûteregels en in tawijde tabel, sadat net-markearre pakketten weromfalle nei de haadtabel wylst markearre pakketten de tunneltabel brûke. Trochstjoerd ferkear fan 'e nammeromte wurdt by it útgean tsjin beliedsrûtering beoardiele, en ôfhinklik fan hoe't dy regels skreaun binne, kin it yn 'e tunneltabel telâne komme.

Twa tafoegings skiede de paden. Gean betiid werom yn 'e mangle-keatling foar de subnet fan 'e nammeromte, en foegje in boarne-basearre regel ta dy't dat subnet yn 'e haadtabel set:

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

Prioriteit 100 sortearret foar de tunnelregels op myn host, dus de gewoane tabel beslút foar dy boarne. Kopiearje it nûmer net blyn: de prioriteiten dy't wg-quick ynstallearret, ferskille tusken ferzjes en tusken de IPv4- en IPv6-opsjes, dus fiere jo ip rule show út en kies in prioriteit dy't foar de tunnelregels op jo masine falt.

Ferifiearje mei in boarnespesifike syktocht ynstee fan op 'e regellist te fertrouwen:

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

As it earste kommando de WireGuard-ynterface rapportearret, is de nije regel noch net foar it tunnelbelied. As it de WAN-ynterface rapportearret wylst it twadde noch de veth-standertrûte sjen lit, binne de host en de nammeromte it net iens en moatte jo beide rûtetabellen opnij lêze.

Start it proses dat de ferbining iepenet

It kommando starte is ien rigel, mar start it proses dat echt de socket oanmakket.ip netns exec clearnet curl -s https://ifconfig.me is de lytste earlike test: it lit it adres sjen dat de nammeromte oan 'e wrâld presintearret, net dat't de host brûke soe.

Foar in tsjinst, hechtsje de nammeromte fia paad oan sadat it proses syn hiele libben deryn bliuwt:

[Service]
NetworkNamespacePath=/run/netns/clearnet

Grafyske applikaasjes binne wêr't de ien-rigel-oanpak stil mislearret. In browser dy't út in menu start wurdt, jout de oanfraach faak oan in eksimplaar dat al bûten de nammeromte rint, dus it nije finster ferskynt en it ferkear giet noch hieltiten troch de tunnel. Jou it in apart profyl sadat in nij eksimplaar echt oanmakke wurdt, en kontrolearje dan de kontekst fan it proses ynstee fan te rieden:

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

De twa útfieringen moatte oerienkomme. Deselde kontrôle wurket foar elk langrinnend programma, en it is de muoite wurdich om it ien kear per applikaasje te dwaan ynstee fan oan te nimmen dat de starter die wat jo bedoelden.

Nammeoplossing hat syn eigen beslút nedich. It meitsjen fan in nammeromte jout it gjin resolver-konfiguraasje; bestannen per nammeromte wurde stipe fia /etc/netns/<name>/resolv.conf en sûnder ien erve jo gedrach dat maklik ferkeard lêzen wurdt. IPv6 hat deselde behanneling nedich: as de nammeromte gjin v6-standertrûte hat wylst de applikaasje v6 foarkomt, kinne oanfragen stûkje foardat se weromfalle, wat liket op in brutsen tunnel.

Kontrolearje de ynkadering, net allinnich it útgongsadres

In wurkjend iepenbier adres bewiist de rûte, net de hiele eask. Rin de rest yn dizze oarder troch:

• ip netns exec clearnet ip route get 1.1.1.1 lit de veth-standertrûte sjen, net de WireGuard-ynterface.
• De FORWARD-tellers op beide regels nimme ta wylst in oanfraach rint.
• It proses fan 'e applikaasje rapportearret de nammeromte-inode dy't jo ferwachtsje.
• Nei in werstart bestiet de nammeromte foardat de tsjinst start; in unit dy't earder rint, mislearret of, slimmer, rint bûten de nammeromte.

Beslút dan wat der barre moat as de tunnel falt. De nammeromte bliuwt wurkjen, dat is it punt fan 'e oefening en ek it risiko: it útsletten programma bliuwt ferbûn wylst al it oare stopt. Skriuw dat as in beliedskeuze op en wês dúdlik oer wat de útsluting net dekt — akkountidentiteit, bewarre browsersteat en jo DNS-provider steane allegear bûten it berik fan in netwurk-nammeromte, en de útsluting as anonymiteit behannelje is de flater dy't de konfiguraasje oerlibbet.