Il kill switch blocca il traffico prima che l'app VPN si avvii?

Un kill switch può coprire o non coprire la finestra che precede l'avvio della sua app, e la differenza la decide la politica del sistema operativo, non la pagina marketing del client. Una casella di avvio automatico dimostra che qualcosa è programmato per partire. Non dimostra che esistano regole di blocco nel momento in cui la rete sale. Sono due eventi, e solo uno dei due protegge il traffico.

Percorrete la lista di controllo in ordine, perché ogni passo restringe ciò che state davvero provando.

Da dove viene davvero il blocco

Esistono due famiglie di implementazione. O la piattaforma installa il blocco, perché conosce il tunnel prima che qualsiasi app venga eseguita, oppure il client installa il blocco stesso dopo l'avvio. La prima può esistere prima dell'accesso. La seconda non può esistere prima del suo processo, per quanto presto quel processo sia pianificato. Stabilite su quale famiglia state contando prima di provare qualsiasi cosa.

Su Android, la VPN sempre attiva combinata con l'impostazione che blocca le connessioni senza VPN è politica della piattaforma, configurata nelle impostazioni di sistema e non solo dentro un client. Sui dispositivi gestiti può essere impostata per voi. Un client che si limita ad avviarsi al boot non è lo stesso meccanismo.

Separate la finestra dal servizio

Una finestra chiusa non è prova che l'applicazione della regola sia cessata, e una finestra aperta non è prova che un tunnel sia pronto. Molti client separano l'interfaccia, il demone e l'app nella barra delle applicazioni. La barra è ciò che vedete; il demone è ciò che tiene le regole.

Provate il componente, non l'icona.

Provate l'intervallo di avvio in sicurezza

L'intervallo da provare inizia al riavvio o all'accesso e termina quando il tunnel si autentica. Le applicazioni in background si connettono in quel periodo, e i controlli degli aggiornamenti sono i colpevoli abituali. Usate attività innocue e la procedura documentata del fornitore invece di bloccare il vostro accesso. Poi ripetete dopo una riconnessione normale, perché il percorso di riconnessione e quello di avvio a freddo eseguono codice diverso.

Un test eseguito dopo che il tunnel è già attivo non dimostra nulla sull'avvio.

Leggete il comportamento al riavvio se la persistenza è il requisito. Un'impostazione può sopravvivere nella configurazione mentre la sua applicazione inizia più tardi, e entrambi i fatti contano: la politica salvata e il momento in cui diventa attiva.

Leggete la politica per ogni piattaforma

Android espone la modalità sempre attiva e il blocco come interruttori separati, ed entrambi devono essere attivi per la protezione prima dell'avvio. Windows ha un concetto di tunnel del dispositivo sempre attivo configurato tramite criteri, che non è lo stesso di un client in modalità utente che si avvia presto. OpenVPN Connect documenta il proprio comportamento di kill switch per piattaforma, e l'ambito documentato è quello che provate. Non portate un nome di impostazione da un sistema all'altro dando per scontato che il significato abbia viaggiato con esso.

Un profilo che richiede una password interattiva ha dipendenze di avvio diverse da quelle di un tunnel macchina.

Cosa registrare

Annotate quale meccanismo è in vigore, in quale fase diventa attivo e quale traffico è stato tentato prima di quella fase. Registrate la versione della piattaforma, perché questo comportamento cambia tra le release e tra configurazioni gestite e personali. Indicate se il client o il sistema possiede la politica, poiché ciò decide chi può correggere una lacuna. Poi ripetete il test dopo ogni aggiornamento del client o del sistema operativo.

Se la lacuna conta, la correzione duratura è la politica della piattaforma, non un ritardo di avvio più breve.

Questa è la risposta alla domanda iniziale, espressa come condizione: un kill switch protegge il traffico prima dell'avvio dell'app solo quando il blocco è installato da qualcosa che esiste prima dell'app.