Linux-nätverksnamnrymder för en VPN: vad de inte isolerar

Starta VPN:en inne i sin egen namnrymd, kör en applikation där, och trafiken lämnar ändå via värdens rutt. Inget är trasigt: namnrymden styr bara processer som går in i den, och läckan kom från en som aldrig gjorde det. Gränssnitt, adresser, rutter, brandväggsregler och sockets är vad namnrymden äger. Filer, konton och redan körande tjänster är det inte, och det är där de flesta överraskningarna kommer ifrån.

Vad namnrymden äger, och var socketen föds

Flytta ett gränssnitt till en namnrymd och värden förlorar det; bygg en tunnel inuti och värden kan inte se den. Det är mekanismen bakom en namnrymdsbegränsad VPN: enheten och rutterna mot den lever i en kontext som bara de valda processerna når. Värden behåller sin standardrutt, så allt utanför förblir orört.

För WireGuard spelar skapandekontexten lika stor roll som nuvarande plats: UDP-socketen binds i den namnrymd där gränssnittet skapades, även efter att enheten flyttats någon annanstans. Vilken routingtabell de krypterade paketen följer beror på den födelseplatsen. När socketen stannar i en kontext utan rutt till peeren slår gränssnittet upp och handskakningen går aldrig ut. Kontrollera dess födelseplats och sedan nuvarande plats.

Vad en namnrymd inte isolerar

Ingenting här skiljer filsystem, konton eller hemligheter, och ingen av dessa gränser uppstår för att du skapade en namnrymd. Resolverkonfigurationen är en fil, så en process inuti kan fortfarande läsa en inställning som pekar på värdens resolver och skicka sin fråga ut genom den rutt det innebär. En applikation som lämnar över begäran till en redan körande mäklare eller systemtjänst involverar en process i en helt annan kontext. Båda är begäranden som gränsen aldrig var avsedd att besvara.

Lösningen är en fil per namnrymd på /etc/netns/<name>/resolv.conf, eller en bind mount av en förberedd fil, riktad mot en resolver som går att nå inifrån. Att redigera /etc/resolv.conf på värden ändrar ingenting av det namnrymden ser.

Placeringen av processer är kontrollen

Den isolering du får är exakt isoleringen av de processer du startar inuti. Ett skal som startas via namnrymdens exec-hjälpare, och allt det avlar, stannar inne; en skrivbordsapplikation som startas från värdens session gör det inte. Skapa kontexten, flytta enheten och bevisa sedan båda sidor:

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

Läs den första wg show inifrån namnrymden och den andra från värden, och förvänta dig att bara en av dem listar peeren. Om båda gör det har enheten aldrig flyttats; om ingen gör det gick den någon annanstans. När startaren är en tjänstehanterare är det unit-filen som ska redigeras, inte skrivbordsgenvägen. En unit utan namnrymdsinställningen startar demonen i värdens kontext och upphäver tyst designen.

Testa från applikationens kontext

Kör kontrollen med samma binärfil och samma användare som applikationen använder, inne i namnrymden. Ta med DNS och båda adressfamiljerna, eftersom en IPv6-rutt du aldrig tänkt på är en vanlig väg ut. Ett test från ditt eget skal bevisar bara att ditt skal är isolerat.

Kör sedan samma kontroll på värden och bekräfta att svaren skiljer sig: tunneladress och avsedd utgång inuti, värdens rutt och kontorets utgång utanför, och resolvern vid namn. Namnge namnrymder efter utrullningen och inte protokollet, så att ett städskript inte förväxlar två av dem.

Vidarebefordran, felpolicy och städning

För en gateway slår du medvetet på vidarebefordran och bestämmer vad som ska hända när tunneln fallerar. En namnrymd blockerar inte rutter du installerar inuti den, så en reservväg till värden används om du skapar en. Det är ett policybeslut, och det bör skrivas ned innan ett avbrott testar det.

Anteckna namnrymdernas namn, gränssnitten och vem som äger konfigurationen, så att städningen bara tar bort det utrullningen skapade. Att återställa värdens nätverk under en återställning gör städning till ett avbrott. Sidan network_namespaces(7) är kort och värd att läsa innan du designar den vägen.