Kill switch per un sidecar VPN: blocca il traffico quando esce

Un container applicativo che condivide lo spazio dei nomi di rete di un container VPN non ha un’interfaccia propria, quindi è facile supporre che non possa inviare nulla quando il tunnel fallisce. Questa supposizione è sbagliata nella modalità di guasto che conta. Se il processo VPN muore mentre lo spazio dei nomi sopravvive, l’applicazione conserva i suoi socket e lo spazio dei nomi conserva le sue rotte, e il traffico continua sul percorso ancora installato. Un vero kill switch è una politica di filtraggio esplicita più test del ciclo di vita del runtime, non una dipendenza all’avvio.

Perché condividere lo spazio dei nomi non è un kill switch

Condividere uno spazio dei nomi significa che l’applicazione usa le interfacce, gli indirizzi e la tabella di routing del container VPN. Elimina il percorso indipendente dell’applicazione verso la rete finché lo spazio dei nomi condiviso è intatto, e non dice nulla su cosa farà quello spazio dei nomi quando il tunnel se ne andrà.

Le condizioni di dipendenza di Compose possono ritardare l’avvio di un’applicazione finché una dipendenza non è sana. Questo copre un solo istante e nessun guasto successivo, quindi è uno strumento di ordinamento dell’avvio e non un firewall di uscita continuo.

Cosa succede davvero quando il container esce

Distingui tre eventi. Il processo VPN dentro il container può morire mentre il container continua a funzionare. Il container può fermarsi o essere rimosso, il che distrugge lo spazio dei nomi. Il container può essere ricreato, il che costruisce un nuovo spazio dei nomi e nuove regole.

Nel primo caso lo spazio dei nomi persiste, la rotta predefinita può ancora puntare all’interfaccia fisica e l’applicazione continua a inviare direttamente. Nel secondo caso l’applicazione dipendente di solito perde del tutto la connettività, perché il suo spazio dei nomi è scomparso. Nel terzo caso l’applicazione può riconnettersi a uno spazio dei nomi nuovo prima che il tunnel sia pronto. Ogni caso richiede un test diverso, e un progetto che copre solo la disconnessione ordinata copre il caso meno interessante.

Costruire una politica di uscita esplicita

Scrivi la politica dentro lo spazio dei nomi condiviso in modo che si applichi ai pacchetti dell’applicazione. La forma è un rifiuto predefinito con eccezioni strette: loopback, l’interfaccia del tunnel e l’indirizzo e la porta specifici dell’endpoint che il trasporto del tunnel richiede.

L’eccezione dell’endpoint deve essere in vigore prima che il tunnel salga, altrimenti il client VPN non può raggiungere il suo server. Per questo il set di regole consente esplicitamente il trasporto esterno invece di consentire l’interfaccia fisica in generale. Aggiungi anche regole IPv6 se lo spazio dei nomi ha connettività IPv6, perché una politica solo IPv4 lascia aperta l’altra famiglia.

Anche il DNS fa parte della politica. Se l’applicazione risolve nomi tramite un resolver raggiungibile solo dentro il tunnel, la regola di rifiuto interromperà la risoluzione quando il tunnel è inattivo, che è il comportamento corretto per un kill switch. Decidi deliberatamente se è quello che vuoi.

Verificare il ciclo di vita, non solo la disconnessione

Invia una richiesta nuova e innocua mentre il tunnel è sano, poi uccidi il processo VPN e inviane un’altra. Ripeti dopo un arresto del container, dopo un riavvio e dopo una ricreazione. Una richiesta nuova conta perché una connessione esistente può sopravvivere a un cambio di regole che blocca quelle nuove.

Non affidarti a un controllo di integrità né a una ricerca dell’IP di uscita come meccanismo di blocco. Un controllo osserva lo stato e lo riporta; una politica controlla il traffico. Le due cose appartengono alla stessa distribuzione, e non sono sostituti.

Registrare le regole perché il test sopravviva a un aggiornamento

Scrivi l’esito atteso per ogni caso di guasto nella documentazione di distribuzione, insieme alle regole che lo implementano. Quella registrazione permette di eseguire lo stesso test dopo un aggiornamento dell’immagine o del runtime, quando il comportamento dello spazio dei nomi o le rotte predefinite possono cambiare senza che nessuno modifichi il file Compose.

Tieni il percorso esterno richiesto dall’endpoint VPN separato dall’uscita applicativa senza restrizioni, e tieni DNS e IPv6 dentro la copertura prevista. Se la politica consente l’intera interfaccia fisica per comodità, il kill switch non c’è più. La documentazione di rete di Docker descrive la disposizione dello spazio dei nomi condiviso su cui si basa la politica, ed è il riferimento da controllare quando il comportamento del runtime è in dubbio.