WireGuard in een netwerknaamruimte: waarom de socket achterbleef

De interface staat in de naamruimte die je wilde, de toepassing is eraan gebonden, en toch verschijnt er nooit tunnelverkeer. Dit is het kenmerk van een WireGuard-apparaat in de Linux-kernel dat in de ene naamruimte is gemaakt en naar een andere is verplaatst: de interface verhuisde en de versleutelde UDP-socket niet. Beide moeten op de juiste plek staan voordat het binnenste verkeer ertoe doet. De controle is snel zodra je weet dat je naar twee contexten moet kijken in plaats van één.

Het symptoom: juiste naamruimte, geen pakketten

Binnen de naamruimte ziet de tunnel er gezond uit. Het apparaat bestaat, adressen zijn toegewezen en de peer-configuratie is aanwezig. Buiten verschijnt de verwachte UDP-uitwisseling nooit op de interface die je volgde, en de andere kant meldt dat er geen handshake was.

De reden is dat de binnenste pakketten van de toepassing het verplaatste apparaat bereiken, en het apparaat ze probeert te versturen via een socket die bij een andere netwerkcontext hoort. De onderliggende route die het gebruikt, en elke firewallregel die daarop van toepassing is, zijn die in de naamruimte waar het apparaat is gemaakt.

Dat is geen fout in de verplaatsing en geen verkeerde configuratie van de peer. Zo werkt de kernelimplementatie, en de naamruimtedocumentatie voor WireGuard beschrijft de aanmaakregel rechtstreeks.

Waarom de socket een geboorteplaats heeft

Een WireGuard-apparaat bezit één UDP-socket voor zijn versleutelde transport, en die socket wordt geopend in de naamruimte waar het apparaat wordt gemaakt. De interface met een linkcommando verplaatsen verplaatst het zichtbare apparaat maar laat het transport waar het begon. De twee objecten hebben dan verschillende eigenaren.

Het gevolg is makkelijk te missen omdat de twee helften op verschillende plekken worden onderzocht. De binnenste route wordt bepaald in de naamruimte waar de toepassing draait, en de buitenste route wordt bepaald waar de socket woont. Alleen een van beide controleren levert een zelfverzekerde maar verkeerde conclusie op. Beide controleren beëindigt het onderzoek meestal in één pass.

Maak hem waar je de socket wilt

De oplossing is het apparaat binnen de doelnaamruimte te maken in plaats van het buiten te maken en te verplaatsen. Ervan uitgaande dat een goedgekeurde naamruimte al bestaat en de naam ongebruikt is:

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

Nu horen zowel de interface als zijn socket bij die context, dus de onderliggende route en de geldende filterregels zijn de daar geconfigureerde. Als het ontwerp de heldere kant elders nodig heeft, plaats dan eerst de onderliggende interface in de naamruimte en maak daarna de tunnel. De volgorde is deel van het ontwerp, geen implementatiedetail.

Behandel ze als netwerkbeheercommando's, niet als een recept. Ze maken een apparaat en tonen de status; sleutels, peers, adressen en routes moeten nog steeds uit een goedgekeurde configuratie komen, en een bestaande productie-interface mag nooit in een voorbeeld worden vervangen.

Lees beide kanten van het pad

Zodra het apparaat op de juiste plek staat, verifieer je de twee beslissingen apart. Begin met de binnenste opzoeking vanuit de context van de toepassing en controleer daarna het buitenste pad vanuit de context die de socket bezit:

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

Als de binnenste opzoeking via de tunnel wordt opgelost en de buitenste opname de versleutelde uitwisseling toont, zijn beide helften het eens. Als de opname leeg is, staat de socket nog ergens anders, of bereikt de onderliggende route in zijn naamruimte het eindpunt niet.

Nog een controle hoort in het dossier: hoe het apparaat na een herstart wordt gemaakt. Een beheerder die de interface met een andere aanmaakcontext opnieuw maakt, verandert de geboorteplaats van de socket. Een handmatige verplaatsing die één keer werkte, is geen bewijs over het beheerde pad.