Linux-nettverksnavnerom for en VPN: hva de ikke isolerer

Start VPN-en inne i sitt eget navnerom, kjør én applikasjon der, og trafikken forlater fortsatt via vertens rute. Ingenting er ødelagt: navnerommet styrer bare prosesser som går inn i det, og lekkasjen kom fra en som aldri gjorde det. Grensesnitt, adresser, ruter, brannmurregler og sockets er det navnerommet eier. Filer, kontoer og tjenester som allerede kjører er det ikke, og det er der de fleste overraskelsene kommer fra.

Hva navnerommet eier, og hvor socketen blir født

Flytt et grensesnitt inn i et navnerom, og verten mister det; bygg en tunnel inni, og verten kan ikke se den. Det er mekanismen bak en navneromsbegrenset VPN: enheten og rutene som peker på den lever i en kontekst bare de valgte prosessene kan nå. Verten beholder standardruten sin, så alt utenfor forblir urørt.

For WireGuard betyr opprettelseskonteksten like mye som gjeldende plassering: UDP-socketen bindes i navnerommet der grensesnittet ble opprettet, selv etter at enheten flytter et annet sted. Hvilken rutetabell de krypterte pakkene følger, avhenger av det fødestedet. Når socketen blir værende i en kontekst uten rute til peeren, slår grensesnittet opp, og håndtrykket forlater aldri. Kontroller fødestedet, deretter gjeldende plassering.

Hva et navnerom ikke isolerer

Ingenting her skiller filsystemer, kontoer eller hemmeligheter, og ingen av disse grensene dukker opp fordi du opprettet et navnerom. Resolverkonfigurasjonen er en fil, så en prosess inni kan fortsatt lese en innstilling som peker på vertens resolver og sende spørringen sin ut gjennom den ruten det innebærer. En applikasjon som overlater forespørselen til en allerede kjørende megler eller systemtjeneste, involverer en prosess i en helt annen kontekst. Begge er forespørsler grensen aldri var ment å besvare.

Løsningen er en fil per navnerom på /etc/netns/<name>/resolv.conf, eller en bind mount av en forberedt fil, rettet mot en resolver som er nåbar innenfra. Å redigere /etc/resolv.conf på verten endrer ingenting av det navnerommet ser.

Plasseringen av prosesser er kontrollen

Isolasjonen du får, er nøyaktig isolasjonen til prosessene du starter inni. Et skall startet gjennom navnerommets exec-hjelper, og alt det avler, blir inne; en skrivebordsapplikasjon startet fra vertens økt blir ikke. Opprett konteksten, flytt enheten, og bevis deretter begge sider:

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

Les den første wg show innenfra navnerommet og den andre fra verten, og forvent at bare én av dem viser peeren. Hvis begge gjør det, har enheten aldri flyttet seg; hvis ingen gjør det, gikk den et annet sted. Når oppstarteren er en tjenestebehandler, er det unit-filen som skal redigeres, ikke skrivebordsnarveien. En unit uten navneromsinnstillingen starter daemonen i vertens kontekst og opphever stille designet.

Test fra applikasjonens kontekst

Kjør kontrollen med samme binærfil og samme bruker som applikasjonen bruker, inne i navnerommet. Ta med DNS og begge adressefamiliene, fordi en IPv6-rute du aldri har tenkt på, er en vanlig vei ut. En test fra ditt eget skall beviser bare at skallet ditt er isolert.

Kjør deretter den identiske kontrollen på verten og bekreft at svarene er forskjellige: tunneladresse og tiltenkt utgang inni, vertens rute og kontorets utgang utenfor, og resolveren ved navn. Navngi navnerom etter utrullingen og ikke protokollen, slik at et oppryddingsskript ikke forveksler to av dem.

Videresending, feilpolitikk og opprydding

For en gateway slår du bevisst på videresending og bestemmer hva som skal skje når tunnelen faller. Et navnerom blokkerer ikke ruter du installerer inni det, så en reservevei til verten blir brukt hvis du lager en. Det er en politisk beslutning, og den bør skrives ned før et utfall tester den.

Noter navneromsnavnene, grensesnittene og hvem som eier konfigurasjonen, slik at oppryddingen bare fjerner det utrullingen opprettet. Å nullstille vertens nettverk under en tilbakerulling gjør opprydding til et utfall. Siden network_namespaces(7) er kort og verdt å lese før du designer den veien.