Un VPN secondario appartiene a un profilo Wi-Fi, non a tutti

Configurate un VPN come secondario della connessione Wi-Fi domestica e tutto funziona, finché il portatile non si unisce a un altro punto di accesso e il tunnel resta inattivo. La nuova connessione è un oggetto di configurazione separato con il proprio UUID, e non ha alcun motivo di conoscere il legame che avete creato per il suo predecessore. Nulla si è guastato; l'associazione semplicemente non è mai esistita.

Il riferimento alle connessioni di NetworkManager definisce i secondari come UUID che si attivano insieme a una determinata connessione di base. Osserva anche che i normali profili VPN non implementano l'attivazione automatica come fanno le connessioni di base. Entrambe le affermazioni portano alla stessa conclusione: l'associazione è per profilo, e qualcuno deve crearla per ciascuno nuovo.

Che cos'è davvero un secondario

Una connessione di base ha un'identità, un UUID e un elenco di secondari. Quando si attiva, il gestore attiva anche quei secondari in ordine, ed è così che un VPN finisce per seguire una rete Wi-Fi senza un clic manuale. La relazione risiede sulla connessione di base, scritta come stringhe UUID anziché come nomi. Questa scelta di rappresentazione non è casuale; è ciò che permette all'associazione di sopravvivere a una rinomina.

Quel dettaglio sui nomi conta più di quanto sembri. Rinominare un profilo VPN lascia intatto il suo UUID, quindi le associazioni esistenti continuano a funzionare. Eliminare il vecchio profilo e importarne uno nuovo produce un nuovo UUID, e ogni associazione che puntava al vecchio ora non punta a nulla.

Esaminate l'elenco esistente prima di aggiungere. Un profilo domestico con un secondario non è una regola che si adatta a ogni SSID; è una riga in un oggetto, e non verrà consultata quando si attiva una base diversa.

Mettete l'associazione dove vengono creati i profili

Su una macchina personale, fate dell'aggancio del secondario previsto una parte dell'aggiunta di ogni profilo Wi-Fi consentito. È un'abitudine più che una funzione, ma un'abitudine che produce uno stato coerente, e costa un comando o due visite alla finestra di dialogo per rete. Tenete una breve nota su quali reti dovrebbero portare il tunnel, perché l'elenco è la politica.

Sui dispositivi gestiti, fate sì che il flusso di provisioning crei la voce Wi-Fi e la sua associazione VPN nello stesso passaggio, e applicate lo stesso trattamento ai profili consentiti che esistono già. Distribuire un profilo VPN da solo lascia le relazioni di base non specificate, ed è così che una flotta finisce con un tunnel che solo metà dei portatili usa.

Dove gli utenti possono ancora creare profili fuori dal percorso gestito, decidete esplicitamente cosa accade a quelle voci. Presumere che ereditino un'associazione non è una politica; è una speranza con un costo di supporto allegato.

Pianificate il cambiamento di identità del VPN

L'origine di provisioning ha bisogno dell'UUID del VPN previsto, non di un nome visualizzato che qualcuno ha indovinato. Quando la manutenzione sostituisce quel VPN con un oggetto appena importato, aggiornate il modello di provisioning e le associazioni esistenti interessate nella stessa modifica. Una rinomina non è una sostituzione, e trattare le due come equivalenti è il modo in cui un'implementazione funzionante si rompe una settimana dopo.

Conservate l'UUID accanto al motivo per cui esiste. Un futuro ingegnere che trovi un UUID nudo in un elenco di secondari non ha modo di dire se è attuale, e probabilmente lo eliminerà mentre riordina.

L'attivazione non è l'applicazione forzata

Una richiesta di secondario avviene al momento dell'attivazione. Non blocca le applicazioni durante l'intervallo prima del completamento dell'autenticazione, e non ferma il traffico dopo che il tunnel fallisce. Sono proprietà diverse, fornite da meccanismi diversi, e confonderle produce un progetto che sembra rigoroso nel profilo ed è permissivo nella pratica.

Bloccare il traffico diretto è una funzione separata con la propria configurazione e i propri modi di guasto, e deve tenere conto del traffico che deve raggiungere la rete prima che qualsiasi tunnel possa esistere: portali captive, pagine di accesso, l'endpoint stesso. Una politica di blocco che non può essere soddisfatta prima dell'autenticazione chiude la macchina fuori dalla rete di cui ha bisogno.

Mettete quella distinzione nelle istruzioni che gli utenti leggono davvero. Una nuova rete Wi-Fi può chiedere il tunnel; l'applicazione forzata decide se qualcosa può uscire quando non riesce a connettersi. Gli utenti a cui viene raccontata solo la prima metà segnaleranno il progetto come rotto.

Provate con un profilo realmente nuovo

Usate una rete di test approvata e un profilo di base appena creato, non la voce domestica che già funziona. Osservate l'attivazione della base, l'UUID secondario richiesto e qualsiasi richiesta di autenticazione in sequenza, e annotate in quale fase si blocca quando si blocca. Un agente segreto che diventa disponibile dopo l'accesso al desktop non è automaticamente presente in ogni contesto di avvio, quindi un riavvio fa parte del piano di test. Poi verificate la risorsa prevista e il percorso di errore: il tunnel si alza prima che l'applicazione ne abbia bisogno, e cosa succede a quell'applicazione quando l'autenticazione fallisce?

Poi verificate la risorsa prevista e il percorso di errore: il tunnel si alza prima che l'applicazione ne abbia bisogno, e cosa succede a quell'applicazione quando il tunnel non riesce ad autenticarsi? Queste due osservazioni sono i criteri di accettazione, e nessuna delle due è visibile nel profilo stesso.