Fail-open o fail-closed: cosa decide un kill switch VPN
Entrambi i termini descrivono cosa succede quando il tunnel non c’è più, non quanto è forte la crittografia. L’ambito che scegli decide se il traffico esce davvero.
Il mito è che fail-closed sia l’impostazione sicura e fail-open quella negligente. Entrambi descrivono cosa succede al traffico una volta che il tunnel è sparito, e nessuno dei due cambia quanto bene quel tunnel crittografa. Una politica fail-closed con un lungo elenco di eccezioni può far uscire più traffico di una politica fail-open su un dispositivo che non lascia mai la rete dell’ufficio. Scegli l’esito che riesci a spiegare a chi possiede il traffico.
L’etichetta descrive un esito, non una forza
Il vocabolario viene dai sistemi di controllo: fail-open consente il funzionamento quando un componente si guasta, fail-closed lo nega. Applicato a una VPN, il componente che si guasta è il tunnel, e la domanda è se al traffico è permesso continuare per un’altra via. La scelta del cifrario, la lunghezza della chiave e il protocollo sono decisioni separate.
La confusione persiste perché un kill switch suona come una funzione di sicurezza, e i fornitori lo vendono come tale. Meccanicamente è una regola di routing e di firewall che blocca il traffico che il tunnel doveva portare, implementata nel client, nel sistema operativo o sul gateway. Lo strato che la applica ne definisce anche la copertura, e una regola in uno strato non ne copre un altro. Una regola sul gateway non può proteggere un portatile che è già passato a un’altra rete.
Che aspetto ha ciascun esito
La stessa politica può comportarsi in modo molto diverso a seconda del guasto che incontri, quindi confronta gli eventi e non le etichette.
| Event | Fail-open result | Fail-closed result |
|---|---|---|
| Tunnel drops while a transfer runs | Transfer continues on the direct path | Transfer stalls until the tunnel returns |
| Client exits or crashes | Rules disappear with the process | Rules persist only if the OS owns them |
| Device boots before sign-in | Normal network access | Blocked until the VPN connects |
| Captive portal needed | Portal loads normally | Portal unreachable without an exception |
| IPv6 not carried by the tunnel | IPv6 traffic leaks directly | Leaks too, unless the block covers IPv6 |
L’ultima riga è quella che coglie chi presume che un kill switch sia un solo interruttore. Una regola scritta per la tabella di routing IPv4 lascia intatta la rotta predefinita IPv6, e l’applicazione può usarla tranquillamente.
L’ambito decide se c’è fuga
Chiedi cosa copre la politica prima di chiedere quale modalità sia. Una regola per applicazione protegge un’app e nient’altro, una regola per l’intero dispositivo protegge tutto tranne le eccezioni, e una regola sul gateway protegge solo il traffico che raggiunge quel gateway. Il DNS ha bisogno di una decisione propria, perché una query inviata a un resolver locale può rivelare nomi anche quando il payload è bloccato.
Le eccezioni di rete locale esistono per stampanti, trasmissione dello schermo e portali captive, e ciascuna è un buco nel blocco. Documentale accanto alla politica, perché chi eredita la configurazione leggerà altrimenti fail-closed come assoluto.
Riconnessione e blocco sono anch’essi controlli separati. Un client può riconnettersi automaticamente senza mai bloccare, o bloccare senza riconnettersi, e la combinazione determina cosa vive un utente durante un’interruzione.
Dimostralo durante una transizione
Testare lo stato stazionario non dimostra nulla. Abbatti il tunnel di proposito e prova l’applicazione che dovrebbe essere protetta, poi controlla se ha raggiunto la rete. Confronta l’indicatore del client con il risultato, perché un indicatore che dice ancora connesso è esattamente il caso per cui esiste la politica. Se l’applicazione protetta riesce, il nome della modalità non conta; hai una fuga.
Ripeti da un avvio a freddo prima dell’accesso, durante un passaggio da Wi-Fi a rete mobile e con l’app protetta in background. Se il blocco è imposto dal processo del client, prova anche cosa succede quando quel processo viene ucciso invece che chiuso in modo pulito.
Infine, controlla il percorso di pulizia. Se un client viene disinstallato mentre le sue regole sono attive, usa la procedura di rimozione documentata dal fornitore invece di disattivare il firewall del sistema operativo, che rimuove protezioni non correlate senza rispondere a chi appartiene la regola rimasta.