Come testare il kill switch di una VPN senza i tuoi account reali
Esegui un test del kill switch con una pagina civetta e un profilo di riserva: copri ogni tipo di interruzione, leggi i codici di uscita di curl e distingui un blocco reale da un guasto DNS.
Non serve un account reale per scoprire se un kill switch tiene; è esattamente ciò che un test mette a rischio. La verifica crea una breve finestra in cui il traffico può o non può uscire fuori dal tunnel, quindi il payload deve essere qualcosa che puoi perdere. Io lo eseguo ora con una pagina civetta e un profilo browser di riserva, e dà una risposta più chiara della routine browser-più-webmail che usavo prima. Quanto segue percorre lo stesso ordine che presenta il client: l'impostazione, la destinazione, la transizione e infine l'evidenza.
Il test risponde a una domanda stretta: durante questa transizione, questa applicazione riesce a raggiungere la rete fuori dal tunnel? Non dice nulla sulla sensatezza del resto della policy. Mantieni lo scopo così ristretto e il risultato vale la pena di essere annotato.
Trova l'interruttore e il suo ambito nel client
Apri il client e individua l'impostazione di blocco prima di cambiare qualsiasi stato di rete. I fornitori la chiamano in modi diversi: kill switch, modalità lockdown, blocco di rete, blocco del traffico fuori dal tunnel. L'etichetta dice meno delle opzioni che contiene. Ciò che conta è se il blocco si applica sempre o solo quando l'app ritiene che un tunnel sia appena fallito, e se copre ogni applicazione o un elenco selezionato.
Poi elenca le transizioni che il tuo client può davvero eseguire. Una disconnessione avviata dall'utente, l'uscita dall'app e la perdita di contatto con il server sono tre percorsi di codice diversi nella maggior parte dei client, e non condividono un'unica policy di blocco. Alcuni rilasciano il blocco all'uscita dell'app. Altri lasciano le regole del filtro installate finché qualcosa non le rimuove. Leggi la documentazione delle impostazioni del fornitore per la build che esegui invece di dare per scontato, poi annota quale delle tre stai testando.
Annota anche il profilo: protocollo, famiglie di indirizzi e se lo split tunnelling è attivo. Un'affermazione valida per l'intero dispositivo non ha senso se il profilo esclude deliberatamente alcune applicazioni, e un'esclusione che hai configurato non è una fuga. La documentazione delle impostazioni di OpenVPN Connect è il tipo di pagina che indica quale interruttore cambia quale comportamento, anche se le etichette variano da client a client.
Scegli una destinazione civetta che funzioni anche senza tunnel
La civetta ha bisogno di due proprietà, e saltarne una produce un risultato illeggibile. Deve essere raggiungibile direttamente quando il tunnel è giù e il blocco è disattivato, altrimenti «ha smesso di rispondere» potrebbe semplicemente significare che l'host non c'è più. E non deve richiedere login, cookie o pagamento, così una fuga ti costa una riga di log invece di una sessione.
Una pagina statica su un host che controlli è la scelta pulita. Una macchina virtuale di riserva che esegue un semplice server HTTP è quasi altrettanto buona, e una pagina pubblica di verifica della connettività funziona se accetti che la sua disponibilità sia fuori dal tuo controllo. Annota l'indirizzo, la porta, la famiglia di indirizzi e se la richiesta richiede una risoluzione del nome, perché ognuno di questi diventa una variabile che potresti dover isolare in seguito.
Stabilisci la baseline prima di toccare l'interruttore. Con il tunnel attivo, la civetta deve rispondere attraverso il tunnel, il che dimostra che la rotta della policy funziona. Con il tunnel giù e il blocco disattivato, deve rispondere direttamente, il che dimostra che la destinazione è viva. Solo allora un fallimento nello stato bloccato ti dice qualcosa.
Esegui le transizioni in un ordine fisso
Prendi le transizioni una alla volta e lascia a ciascuna qualche secondo per assestarsi, perché i client spesso smontano e ricostruiscono le regole in quell'intervallo. Eseguire ogni volta lo stesso breve controllo mantiene le osservazioni confrontabili:
curl -sS -o /dev/null -w 'http=%{http_code}\n' --max-time 5 http://decoy.example/
echo "curl_exit=$?"
dig +short decoy.example
curl -6 -sS -o /dev/null -w 'v6_http=%{http_code}\n' --max-time 5 http://decoy.example/
echo "curl_v6_exit=$?"| Transition | Expected with the block on | Failure signature |
|---|---|---|
| Manual disconnect | Decoy stops answering within seconds | Decoy still returns 200 |
| Server or path failure | Blocked, with no exemption for the old endpoint | Direct access during the gap |
| Quit the app | Client-dependent; record what happens | Block disappears with the process |
| Wi-Fi to Ethernet | Block holds until the tunnel returns | Traffic flows mid-change |
La riga dell'uscita dall'app merita una sua esecuzione anche se non chiudi mai il client nell'uso normale. Se il blocco si rilascia all'uscita, un crash o un aggiornamento forzato ti consegnano la stessa esposizione, e questo è un fatto sulla distribuzione, non sulla tua pazienza. Su Windows le sonde equivalenti sono Resolve-DnsName decoy.example e curl.exe -s -o NUL -w "%{http_code}" http://decoy.example/.
Distingui un blocco da un resolver rotto
Una pagina che non si carica ha diverse cause, e solo una è l'interruttore che funziona. Se il nome non si risolve, hai scoperto che il DNS è bloccato o rotto, non che il percorso dati è bloccato. Sonda anche un indirizzo letterale, così la risposta non dipende affatto dalla risoluzione.
I codici di uscita di curl separano questi casi: 6 è un errore di risoluzione del nome, 7 significa che la connessione è stata rifiutata, 28 è un timeout. Una rotta bloccata di solito si presenta come timeout o rifiuto verso un indirizzo letterale. Un blocco solo DNS lascia 6 e nasconde tutto il resto. Una pagina in cache o un portale captive ingannano l'occhio, ed è per questo che l'evidenza è il codice di uscita, non lo schermo.
Ripeti la sonda su IPv6 con un indirizzo letterale. Un blocco che copre IPv4 e ignora IPv6 è abbastanza comune da meritare una riga propria nei tuoi appunti, e un client che disabilita IPv6 fuori dal tunnel dovrebbe fallire in modo pulito su entrambe le famiglie.
Annota l'ambito che il risultato copre
Quando il tunnel è tornato, conferma il ripristino: la civetta risponde attraverso il tunnel, il resolver restituisce risposte e la policy è dove l'hai lasciata. Poi annulla gli esperimenti. Una regola firewall temporanea, una rotta di debug o un profilo di test lasciati in posizione confonderanno la prossima esecuzione e possono sopravvivere all'app.
Una singola esecuzione copre una build del client, un profilo, una transizione e una famiglia di indirizzi. Annota questi quattro elementi con l'esito:
- Build e piattaforma del client, e se l'impostazione è per profilo o globale.
- Profilo, protocollo e qualsiasi esclusione dello split tunnel.
- Transizione testata, e come l'hai innescata.
- Famiglie di indirizzi e DNS, con i codici di uscita di curl per lo stato bloccato e non bloccato.
Se una riga è vuota, il test non è finito. Il roaming significa ripetere la riga del cambio di rete. Un riavvio non presidiato significa verificare che le regole tornino, che è una domanda sull'ordine di ripristino più che sull'interruttore. Ripeti la sequenza dopo un aggiornamento del client, perché gli interruttori cambiano raramente mentre il comportamento dietro di essi cambia. Tieni la civetta: niente da ruotare, e il prossimo controllo richiede cinque minuti.