Spazi dei nomi di rete Linux per una VPN: cosa non isolano

Avviate la VPN dentro il suo spazio dei nomi, eseguite lì un’applicazione, e il traffico esce comunque dalla rotta dell’host. Niente è rotto: lo spazio dei nomi governa solo i processi che vi entrano, e la fuga è venuta da uno che non vi è mai entrato. Interfacce, indirizzi, rotte, regole del firewall e socket sono ciò che lo spazio dei nomi possiede. I file, gli account e i servizi già in esecuzione no, ed è da lì che arrivano la maggior parte delle sorprese.

Cosa possiede lo spazio dei nomi, e dove nasce il socket

Spostate un’interfaccia in uno spazio dei nomi e l’host la perde; costruiteci dentro un tunnel e l’host non può vederlo. È il meccanismo di una VPN limitata a uno spazio dei nomi: il dispositivo e le rotte che puntano a esso vivono in un contesto che solo i processi scelti raggiungono. L’host mantiene la sua rotta predefinita, quindi tutto ciò che sta fuori resta intatto.

Per WireGuard il contesto di creazione conta quanto la posizione attuale: il socket UDP è legato nello spazio dei nomi in cui è stata creata l’interfaccia, anche dopo che il dispositivo si sposta altrove. Da quale tabella di routing dipendono i pacchetti cifrati dipende da quel luogo di nascita. Quando il socket resta in un contesto senza rotta verso il peer, l’interfaccia interroga e la stretta di mano non esce mai. Controllate il suo luogo di nascita, poi la posizione attuale.

Cosa uno spazio dei nomi non isola

Niente qui separa filesystem, account o segreti, e nessuno di questi confini appare perché avete creato uno spazio dei nomi. La configurazione del resolver è un file, quindi un processo all’interno può ancora leggere un’impostazione che punta al resolver dell’host e inviare la sua query attraverso la rotta che ciò implica. Un’applicazione che consegna la richiesta a un intermediario o a un servizio di sistema già in esecuzione coinvolge un processo in un contesto del tutto diverso. Entrambe sono richieste a cui il confine non è mai stato pensato per rispondere.

La soluzione è un file per spazio dei nomi in /etc/netns/<name>/resolv.conf, o un bind mount di un file preparato, puntato a un resolver raggiungibile dall’interno. Modificare /etc/resolv.conf sull’host non cambia nulla di ciò che lo spazio dei nomi vede.

Il posizionamento dei processi è il controllo

L’isolamento che ottenete è esattamente quello dei processi che avviate all’interno. Una shell avviata tramite l’assistente exec dello spazio dei nomi, e tutto ciò che genera, resta dentro; un’applicazione desktop lanciata dalla sessione dell’host no. Create il contesto, spostate il dispositivo, poi dimostrate entrambi i lati:

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

Leggete il primo wg show dall’interno dello spazio dei nomi e il secondo dall’host, e aspettatevi che solo uno dei due elenchi il peer. Se lo fanno entrambi, il dispositivo non si è mai spostato; se nessuno lo fa, è andato altrove. Quando l’elemento di avvio è un gestore di servizi, il file unit è quello da modificare, non il collegamento sul desktop. Un’unit senza l’impostazione dello spazio dei nomi avvia il demone nel contesto dell’host e annulla silenziosamente il progetto.

Provate dal contesto dell’applicazione

Eseguite il controllo con lo stesso binario e lo stesso utente che usa l’applicazione, all’interno dello spazio dei nomi. Includete il DNS ed entrambe le famiglie di indirizzi, perché una rotta IPv6 che non avete mai considerato è una via d’uscita comune. Un test dalla vostra shell dimostra solo che la vostra shell è isolata.

Poi eseguite lo stesso controllo sull’host e confermate che le risposte differiscono: indirizzo del tunnel e uscita prevista dentro, rotta dell’host e uscita dell’ufficio fuori, e il resolver per nome. Nominate gli spazi dei nomi in base al deployment anziché al protocollo, così uno script di pulizia non ne confonde due.

Inoltro, politica di guasto e pulizia

Per un gateway, attivate l’inoltro deliberatamente e decidete cosa deve succedere quando il tunnel cade. Uno spazio dei nomi non blocca le rotte che installate al suo interno, quindi una rotta di riserva verso l’host verrà usata se ne create una. È una decisione di politica, e andrebbe scritta prima che un’interruzione la metta alla prova.

Annotate i nomi degli spazi dei nomi, le interfacce e chi possiede la configurazione, così la pulizia rimuove solo ciò che il deployment ha creato. Reimpostare la rete dell’host durante un rollback trasforma una pulizia in un’interruzione. La pagina network_namespaces(7) è breve e vale la pena leggerla prima di progettare quel percorso.