Linux-netwerknaamruimtes voor een VPN: wat ze niet isoleren

Start de VPN binnen zijn eigen naamruimte, draai er één toepassing, en verkeer verlaat het systeem nog steeds via de route van de host. Niets is stuk: de naamruimte beheert alleen processen die erin komen, en het lek kwam van een proces dat dat nooit deed. Interfaces, adressen, routes, firewallregels en sockets zijn wat de naamruimte bezit. Bestanden, accounts en al draaiende diensten niet, en daar komen de meeste verrassingen vandaan.

Wat de naamruimte bezit, en waar de socket geboren wordt

Verplaats een interface naar een naamruimte en de host raakt hem kwijt; bouw erbinnen een tunnel en de host kan hem niet zien. Dat is het mechanisme achter een naamruimtegebonden VPN: het apparaat en de routes ernaartoe leven in een context die alleen de gekozen processen bereiken. De host houdt zijn standaardroute, dus alles buiten blijft onaangeroerd.

Bij WireGuard telt de aanmaakcontext even zwaar als de huidige locatie: de UDP-socket wordt gebonden in de naamruimte waar de interface is aangemaakt, zelfs nadat het apparaat ergens anders heen gaat. Welke routetabel de versleutelde pakketten volgen, hangt van die geboorteplaats af. Blijft de socket in een context zonder route naar de peer, dan kijkt de interface op en de handshake gaat er nooit uit. Controleer de geboorteplaats, dan de huidige locatie.

Wat een naamruimte niet isoleert

Niets hier scheidt bestandssystemen, accounts of geheimen, en geen van die grenzen ontstaat doordat je een naamruimte hebt gemaakt. De resolverconfiguratie is een bestand, dus een proces binnenin kan nog steeds een instelling lezen die naar de resolver van de host wijst en zijn query versturen via de route die dat impliceert. Een toepassing die het verzoek aan een al draaiende broker of systeemdienst geeft, betrekt een proces in een heel andere context. Beide zijn verzoeken die de grens nooit had moeten beantwoorden.

De oplossing is een bestand per naamruimte op /etc/netns/<name>/resolv.conf, of een bind mount van een voorbereid bestand, gericht op een resolver die van binnenuit bereikbaar is. /etc/resolv.conf op de host bewerken verandert niets van wat de naamruimte ziet.

De plaatsing van processen is de controle

De isolatie die je krijgt is precies de isolatie van de processen die je erbinnen start. Een shell die via de exec-hulp van de naamruimte is gestart, en alles wat die voortbrengt, blijft binnen; een desktoptoepassing die vanuit de hostsessie wordt gestart, niet. Maak de context, verplaats het apparaat en bewijs daarna beide kanten:

ip netns add vpn1
ip link set wg0 netns vpn1
ip netns exec vpn1 wg show
wg show

Lees de eerste wg show van binnen de naamruimte en de tweede van de host, en verwacht dat slechts één van beide de peer vermeldt. Als beide dat doen, is het apparaat nooit verplaatst; als geen van beide, is het ergens anders heen gegaan. Als de starter een servicemanager is, is het unitbestand wat bewerkt moet worden, niet de snelkoppeling op het bureaublad. Een unit zonder de naamruimte-instelling start de daemon in de hostcontext en maakt het ontwerp stil ongedaan.

Test vanuit de context van de toepassing

Voer de controle uit met hetzelfde binaire bestand en dezelfde gebruiker als de toepassing, binnen de naamruimte. Neem DNS en beide adresfamilies mee, want een IPv6-route waar je nooit aan hebt gedacht is een veelvoorkomende uitweg. Een test vanuit je eigen shell bewijst alleen dat je shell geïsoleerd is.

Voer daarna dezelfde controle op de host uit en bevestig dat de antwoorden verschillen: tunneladres en bedoelde uitgang binnen, hostroute en kantooruitgang buiten, en de resolver op naam. Noem naamruimtes naar de uitrol en niet naar het protocol, zodat een opruimscript er twee niet door elkaar haalt.

Doorsturen, foutbeleid en opruimen

Schakel voor een gateway doorsturen bewust in en beslis wat er moet gebeuren als de tunnel valt. Een naamruimte blokkeert geen routes die je erin installeert, dus een terugvalroute naar de host wordt gebruikt als je er een maakt. Dat is een beleidsbeslissing, en die zou moeten worden opgeschreven voordat een storing hem test.

Leg de naamruimtenamen, de interfaces en de eigenaar van de configuratie vast, zodat opruimen alleen verwijdert wat de uitrol heeft gemaakt. Het netwerk van de host resetten tijdens een terugdraaiing maakt van opruimen een storing. De pagina network_namespaces(7) is kort en de moeite waard voordat je dat pad ontwerpt.