WireGuard yn in netwurknammeromte: wêrom’t de socket efterbleau

De ynterface stiet yn ’e nammeromte dy’t jo woene, de applikaasje is deroan bûn, en dochs ferskynt nea tunnelferkear. Dat is it skaaimerk fan in WireGuard-apparaat yn ’e Linux-kearn dat yn ien nammeromte makke en nei in oare ferpleatst waard: de ynterface ferpleatste en syn fersifere UDP-socket net. Beide moatte op it goede plak wêze foardat it ynderlike ferkear fan belang is. De kontrôle is fluch as jo ienris witte dat jo twa konteksten besjen moatte ynstee fan ien.

It symptoom: goede nammeromte, gjin pakketten

Binnen de nammeromte sjocht de tunnel sû n. It apparaat bestiet, adressen binne tawiisd, en de konfiguraasje fan ’e partner is oanwêzich. Bûten ferskynt de ferwachte UDP-útwikseling nea op ’e ynterface dy’t jo besochten, en de oare kant meldt dat der gjin hânskodding wie.

De reden is dat de ynderlike pakketten fan ’e applikaasje it ferpleatste apparaat berikke, en it apparaat besiket se te stjoeren troch in socket dy’t ta in oare netwurkkontekst heart. De ûnderlizzende rûte dy’t it brûkt, en elke firewallregel dy’t dêrop fan tapassing is, binne dy yn ’e nammeromte dêr’t it apparaat makke waard.

Dat is gjin fout yn ’e ferpleatsing en ek gjin ferkearde konfiguraasje fan ’e partner. Sa docht de kearnimplementaasje, en de dokumintaasje oer nammeromten foar WireGuard beskriuwt de meitsjeregel direkt.

Wêrom’t de socket in berteplak hat

In WireGuard-apparaat hat ien UDP-socket foar syn fersifere transport, en dy socket wurdt iepene yn ’e nammeromte dêr’t it apparaat makke wurdt. It ferpleatsen fan ’e ynterface mei in keppelkommando ferpleatst it sichtbere apparaat, mar lit it transport bliuwe dêr’t it begon. Dan hawwe de twa objekten ferskate eigners.

It gefolch is maklik te missen om’t de beide helten op ferskate plakken besjoen wurde. De ynderlike rûte wurdt besletten yn ’e nammeromte dêr’t de applikaasje rint, en de uterlike rûte wurdt besletten dêr’t de socket libbet. Allinnich ien fan beide kontrolearje jout in selsbetrouwen, mar ferkeard beslút. Beide kontrolearje einiget it ündersyk meastentiids yn ien passe.

Meitsje it dêr’t jo de socket wolle

De oplossing is it apparaat binnen de doelnammeromte te meitsjen ynstee fan it bûten te meitsjen en te ferpleatsen. Oannommen dat in goedkarde nammeromte al bestiet en de namme net brûkt wurdt:

ip netns exec vpn-apps ip link add wg-demo type wireguard
ip netns exec vpn-apps wg show

No hearre sawol de ynterface as syn socket ta dy kontekst, dus de ûnderlizzende rûte en de jildende filterregels binne dy’t dêr konfigurearre binne. As it ûntwerp de heldere kant earne oars nedich hat, set dan earst de ûnderlizzende ynterface yn ’e nammeromte en meitsje dêrnei de tunnel. Oarder is part fan it ûntwerp, net in ymplemintaasjedetail.

Behannelje dizze as netwurkbehearkommando’s, net as in resept. Se meitsje in apparaat en toane tastân; kaaien, partners, adressen en rûtes moatte noch altyd út in goedkarde konfiguraasje komme, en in besteande produksje-ynterface moat nea yn in foarbyld set wurde.

Lês beide kanten fan it paad

As it apparaat op it goede plak is, kontrolearje dan de twa besluten apart. Begjin mei de ynderlike syktocht út ’e kontekst fan ’e applikaasje, en kontrolearje dan it uterlike paad út ’e kontekst dy’t de socket hat:

ip netns exec vpn-apps ip route get 10.30.0.9
ip netns exec vpn-apps wg show
tcpdump -ni any udp port 51820

As de ynderlike syktocht troch de tunnel oplost en de uterlike opname de fersifere útwikseling sjen lit, binne beide helten iens. As de opname leech is, is de socket noch earne oars, of de ûnderlizzende rûte yn syn nammeromte berikt it einpunt net.

Noch ien kontrôle heart yn ’e rekord: hoe’t it apparaat nei in werstart makke wurdt. In behearder dy’t de ynterface mei in oare meitsjekontekst opnij makket, feroaret it berteplak fan ’e socket. In hânmjittige ferpleatsing dy’t ienris wurke, is gjin bewiis oer it behearde paad.