Begin die VPN binne sy eie naamruimte, laat een toepassing daar loop, en verkeer verlaat steeds via die gasheervoete. Niks is stukkend nie: die naamruimte beheer net prosesse wat dit binnegaan, en die lek het gekom van een wat dit nooit gedoen het nie. Koppelvlakke, adresse, roetes, vuurmuurreëls en sokkels is wat die naamruimte besit. Lêers, rekeninge en dienste wat reeds loop, is nie, en dit is waar die meeste verrassings vandaan kom.

Wat die naamruimte besit, en waar die sokkel gebore word

Skuif ’n koppelvlak in ’n naamruimte in en die gasheer verloor dit; bou ’n tonnel binne en die gasheer kan dit nie sien nie. Dit is die meganisme agter ’n naamruimte-gebonde VPN: die toestel en die roetes wat daarheen wys, leef in ’n konteks wat net die gekose prosesse kan bereik. Die gasheer hou sy verstekroete, so alles buite bly ongeraak.

Die skeppingskonteks maak net soveel saak soos die huidige ligging vir WireGuard: die UDP-sokkel word gebind in die naamruimte waar die koppelvlak geskep is, selfs nadat die toestel elders heen beweeg. Watter roetetabel die geënkripteerde pakkette volg, hang van daardie geboorteplek af. Wanneer die sokkel in ’n konteks bly met geen roete na die eweknie nie, kyk die koppelvlak op en die handdruk verlaat nooit. Kyk na sy geboorteplek, dan na sy huidige ligging.

Wat ’n naamruimte nie isoleer nie

Niks hier skei lêerstelsels, rekeninge of geheime nie, en nie een van daardie grense verskyn omdat jy ’n naamruimte geskep het nie. Resolver-konfigurasie is ’n lêer, so ’n proses binne kan steeds ’n instelling lees wat na die gasheer-resolver wys en sy navraag uitstuur deur watter roete dit ook al impliseer. ’n Toepassing wat die versoek aan ’n reeds lopende makelaar of stelseldiens oorhandig, betrek ’n proses in ’n heeltemal ander konteks. Albei is versoeke wat die grens nooit bedoel was om te antwoord nie.

Die oplossing is ’n per-naamruimte lêer by /etc/netns/<name>/resolv.conf, of ’n bind-montering van ’n voorbereide lêer, wat na ’n resolver wys wat van binne bereikbaar is. Om /etc/resolv.conf op die gasheer te wysig, verander niks wat die naamruimte sien nie.

Prosesplasing is die beheer

Die isolasie wat jy kry, is presies die isolasie van die prosesse wat jy binne begin. ’n Dop wat deur die naamruimte se exec-hulp begin is, en alles wat dit voortbring, bly binne; ’n lessenaartoepassing wat vanuit die gasheersessie begin is, nie. Skep die konteks, skuif die toestel, en bewys dan albei kante:

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

Lees die eerste wg show van binne die naamruimte en die tweede van die gasheer, en verwag dat net een van hulle die eweknie lys. As albei dit doen, het die toestel nooit beweeg nie; as nie een dit doen nie, het dit elders heen gegaan. Wanneer die lanseerder ’n diensbestuurder is, is die eenheidlêer wat gewysig moet word, nie die lessenaarskortpad nie. ’n Eenheid sonder die naamruimte-instelling begin die daemon in die gasheerkonteks en maak die ontwerp stilweg ongedaan.

Toets vanuit die toepassingskonteks

Voer die kontrole uit met dieselfde program en dieselfde gebruiker wat die toepassing gebruik, binne die naamruimte. Sluit DNS en albei adresfamilies in, want ’n IPv6-roete waaraan jy nooit gedink het nie, is ’n algemene uitweg. ’n Toets vanuit jou eie dop bewys net dat jou dop geïsoleer is.

Voer dan dieselfde kontrole op die gasheer uit en bevestig dat die antwoorde verskil: tonneladres en beoogde uitgang binne, gasheerroete en kantooruitgang buite, en die resolver by naam. Noem naamruimtes na die ontplooiing eerder as die protokol, sodat ’n opruimingskrip nie twee van hulle kan verwar nie.

Aansturing, foutbeleid en opruiming

Vir ’n poort, skakel aansturing doelbewus aan en besluit wat moet gebeur wanneer die tonnel val. ’n Naamruimte blokkeer nie roetes wat jy daarbinne installeer nie, so ’n terugvalroete na die gasheer sal gebruik word as jy een skep. Dit is ’n beleidsbesluit, en dit moet neergeskryf word voordat ’n onderbreking dit toets.

Teken die naamruimtename, die koppelvlakke en wie die konfigurasie besit aan, sodat opruiming net verwyder wat die ontplooiing geskep het. Om die gasheernetwerk tydens ’n terugrol te herstel, verander ’n opruiming in ’n onderbreking. Die network_namespaces(7) bladsy is kort en die moeite werd om te lees voordat jy daardie pad ontwerp.

Verwante artikels