Interruttore di sicurezza VPN: quale traffico blocca e quando

Due funzioni vengono descritte con la stessa parola e svolgono compiti diversi. La riconnessione automatica cerca di riportare su il tunnel, e può riuscirci in un secondo mentre le richieste falliscono in quel varco. L'interruttore decide cosa accade al traffico durante quel varco. Leggere un client come se le due cose fossero un'unica impostazione è il modo in cui le persone finiscono per fidarsi di un'icona invece che di una policy.

Bloccare e riconnettersi sono decisioni separate

Un client blocca solo quando la perdita è imprevista, poi si riconnette e toglie il blocco. Un altro mantiene un blocco a livello di sistema finché qualcuno non cambia un'impostazione a mano, e un terzo tratta una disconnessione deliberata come permesso di ripristinare l'accesso ordinario. Sono tre comportamenti diversi, e la documentazione del fornitore dice quale implementa la tua build.

L'importazione di un profilo non decide nulla su questa domanda. Lo stesso profilo server si carica in due client con comportamenti di blocco opposti, perché il profilo porta impostazioni e non una promessa. È anche per questo che una casella su desktop e un interruttore su mobile con etichette simili possono implementare regole diverse. Leggi la descrizione accanto al controllo sulla tua piattaforma, poi verifica cosa fa.

Lo stesso profilo si comporta diversamente in due client

Le impostazioni dell'app OpenVPN Connect descrivono una modalità tunnel che trattiene il traffico ordinario solo finché il client segnala uno stato di pausa o di riconnessione, il che è più stretto di una promessa generale su ogni evento e su ogni piattaforma. Leggi gli stati elencati, non il nome del prodotto. Una descrizione scritta per una build del client non si trasferisce al client di un altro fornitore.

Android mostra la stessa parola per due controlli, perché la VPN sempre attiva e il blocco delle connessioni senza VPN sono documentati separatamente. Un client desktop con una casella dal nome simile può implementare qualcosa di più stretto o più ampio di entrambi. Considera un'etichetta condivisa in due menu una coincidenza finché non sono state lette entrambe le descrizioni. I dispositivi gestiti aggiungono un terzo livello, perché un profilo del dispositivo può imporre un'impostazione che l'utente non vede e non può annullare.

Impostazioni di piattaforma simili non sono equivalenti

Confronta il controllo che vedi con la policy che si applica davvero. Su un dispositivo gestito l'interruttore visibile può essere in grigio, oppure attivo mentre un profilo di livello superiore impone il contrario. Chiedi la policy effettiva invece di quella locale, e ottieni la risposta per iscritto.

Annota che cosa afferma ogni livello prima di testare qualcosa, perché i due spesso non concordano e la discordanza si perde facilmente appena iniziano i test. Un dispositivo che blocca correttamente durante un test può stare bloccando per un motivo che nessuno ha documentato.

Esegui un evento alla volta e annota il codice

Verifica un evento per esecuzione, con una richiesta innocua, e fai di ogni tentativo una richiesta nuova invece di una pagina forse già in cache. I comandi sotto abbassano il tunnel, chiedono una pagina e mostrano se l'interfaccia è tornata.

ip link set tun0 down
curl -s -o /dev/null -w "%{http_code}\n" --max-time 5 https://example.com
ip -brief address show tun0

La tabella collega ogni azione all'osservazione che conta e all'evidenza che vale la pena conservare. Una richiesta che fallisce entro il timeout dice che il blocco è entrato in azione; una richiesta che passa dice che il traffico ha trovato un'altra via, che può essere una rotta esclusa e non un blocco disattivato. Ripeti l'intero insieme dopo un aggiornamento software significativo o un cambio di policy di instradamento, perché entrambi possono cambiare il ramo senza che si muova alcuna impostazione visibile. Alla fine vuoi un comportamento di guasto prevedibile, non un'icona rassicurante.

Eccezioni, portali per ospiti e ciò che un blocco non può fare

L'accesso alla rete locale è l'eccezione comune, e cambia la portata della promessa. Un client può raggiungere una stampante sulla stessa sottorete mentre blocca tutto il resto, cosa ragionevole a casa e discutibile su una rete per ospiti. Decidi se quell'eccezione è desiderata prima che un incidente la scopra per te.

Un blocco rigoroso rende anche scomodo l'accesso al portale di una rete per ospiti, perché il portale è esattamente il traffico diretto che il blocco esiste per fermare. Impara il modo supportato di autorizzare la rete, poi ripristina la policy di proposito invece di spegnere controlli finché una pagina si carica. Tieni la risposta del resolver e la tabella di routing nella stessa nota, come sotto. Ciò che un interruttore non può fare è rendere il servizio anonimo, perché bloccare il traffico fuori dal tunnel non dice nulla su ciò che accade dentro.

resolvectl query example.com
ss -tunp | grep -v tun0