Cosa preconfigurare prima della prima connessione VPN di un utente

Una prima connessione VPN raramente fallisce al tunnel. Fallisce quando un utente comune, su una rete non gestita, segue istruzioni scritte da qualcuno che aveva già installato il certificato. Il profilo, la catena di fiducia e la credenziale sono configurazione, e tutti e tre possono essere distribuiti prima che l'utente sia coinvolto. Ciò che resta a quell'utente dovrebbero essere quattro azioni senza decisioni al loro interno. Ogni passaggio extra lasciato nella consegna diventa una chiamata al supporto che inizia con qualcuno che legge ad alta voce una finestra di dialogo.

Cosa porta davvero un profilo di connessione

Un profilo VPN non è un collegamento né un segnalibro. È un oggetto con nome nell'archivio delle connessioni del sistema operativo, che contiene l'indirizzo del server, il tipo di tunnel, il metodo di autenticazione e spesso le route, i suffissi DNS e le regole di attivazione che decidono quando si connette. Su Windows quei campi corrispondono ai nodi del provider del servizio di configurazione VPNv2, per questo un profilo può arrivare tramite Intune, Configuration Manager, un pacchetto di provisioning o un file XML importato a mano.

Il client applica quell'oggetto in un ordine fisso: valida il certificato del server contro radici attendibili, negozia il tunnel e solo dopo applica routing e risoluzione dei nomi prima che un'applicazione veda una rete. Quest'ordine spiega la maggior parte delle segnalazioni di una connessione che dice di essere attiva mentre non carica nulla: l'autenticazione è riuscita e ciò che è davvero fallito è il DNS o l'elenco delle route. Leggere il profilo come un unico oggetto con una sequenza, non come un insieme di interruttori indipendenti. Una radice di fiducia mancante fallisce al primo passo, prima che venga offerta qualsiasi credenziale, ed è per questo che produce un errore generico invece di una richiesta di accesso.

Il materiale di fiducia è il campo che più spesso viene introdotto di nascosto a mano. Il certificato CA che firma il gateway deve essere presente prima del primo tentativo, e la validazione del nome del server deve restare attiva con un nome corrispondente; disattivare la validazione per far passare un test trasforma un problema di autenticazione in un'intercettazione silenziosa che nessun utente può rilevare.

Le quattro scelte che gli utenti non dovrebbero mai fare

Protocollo e tipo di tunnel vengono per primi: scegliere una combinazione supportata per piattaforma e documentare il lato gateway, perché un nome di marca familiare non è una dichiarazione di compatibilità. Poi l'endpoint: un solo nome host che si risolva pubblicamente e corrisponda al certificato presentato dal gateway. L'autenticazione appartiene al sistema di identità, che si tratti di un certificato, di un nome utente con secondo fattore o di entrambi. Nessuna di queste è una preferenza dell'utente, e nessuna dovrebbe comparire come domanda nelle istruzioni.

La quarta scelta è la portata: tunnel completo o tunnel diviso, e quali prefissi e suffissi DNS viaggiano al suo interno. Un tunnel diviso senza suffissi interni fa trapelare la risoluzione dei nomi verso qualunque resolver offra la rete locale, e un tunnel completo senza un piano per le risorse locali rompe stampanti e portali captive. Entrambe sono decisioni dell'amministratore con effetti visibili all'utente, ed è proprio per questo che l'utente dovrebbe riceverle già stabilite.

Mantenere il nome della connessione noioso e stabile. Gli utenti lo leggono ad alta voce al supporto, lo cercano in un elenco del client e lo ricordano tra un ripristino della password e l'altro; rinominarlo a metà di una migrazione crea un picco di supporto che non ha nulla a che vedere con il funzionamento della VPN.

Distribuire l'identità per persona o per dispositivo

Il profilo è pubblico e la chiave privata no. Un errore comune di distribuzione è esportare un profilo funzionante insieme al suo certificato e far circolare il file, il che rende ogni portatile un clone di una sola identità e trasforma la revoca in una decisione tutto o niente. Registrare invece le credenziali tramite il processo supportato: un certificato per dispositivo dal canale di gestione, o una credenziale per utente dal provider di identità.

I tunnel di dispositivo e i tunnel utente si autenticano in momenti diversi, e quella differenza decide quale credenziale serve. Un tunnel di dispositivo che si connette prima dell'accesso richiede un certificato macchina e un profilo disponibile al sistema. Un tunnel utente che parte dopo l'accesso può usare la credenziale dell'utente stesso e non dovrebbe richiedere diritti di amministratore. Aggiungere accesso di rete a livello macchina solo per togliere un clic dalla mattina di qualcuno è un cattivo scambio, perché amplia ciò che un dispositivo incustodito può raggiungere.

La registrazione è anche il punto in cui si decide il percorso di ripristino. Un rinnovo del certificato o un cambio di password deve raggiungere il dispositivo mentre il tunnel è abbassato, quindi provisioning, provider di identità e gateway devono concordare come avviene; se l'unico modo per riparare un profilo è attraverso il tunnel che quel profilo fornisce, la chiave è chiusa dentro la scatola.

Far corrispondere il canale di consegna al client

I client nativi e di terze parti vengono distribuiti in modo diverso. I profili di Windows possono essere distribuiti come VPNv2 ProfileXML tramite Intune o Configuration Manager, ma non ogni nodo è esposto in ogni superficie di gestione, e le impostazioni di routing, DNS e attivazione variano per strumento e per versione di Windows. Confermare quale campo è distribuibile prima di promettere una distribuzione senza intervento, perché il riferimento sulle opzioni del profilo documenta impostazioni che alcuni percorsi di distribuzione non riescono ancora a definire.

I client dei fornitori aggiungono un secondo strato, poiché il binario, il profilo e la policy dell'headend sono artefatti separati. Cisco Secure Client, per esempio, supporta la pre-distribuzione sia del pacchetto sia del suo profilo, e la versione del client va coordinata con la configurazione del gateway; installare solo il pacchetto lascia l'utente dentro una procedura guidata.

Qualunque canale si scelga, mantenere un'unica fonte di verità per il profilo. Un profilo riparato che un pacchetto più vecchio sovrascrive al controllo successivo è un incidente ricorrente, e la correzione duratura è una configurazione con versioni anziché una modifica manuale su ogni macchina.

Provare la consegna come utente nuovo, poi provare il ripristino

Fare il pilota con un account comune su un dispositivo che non si è mai connesso, senza la sessione salvata dell'amministratore né un certificato pre-registrato. Confermare che il profilo compaia nell'elenco, che la richiesta di accesso corrisponda alle istruzioni e che si apra una risorsa interna con nome, poi controllare la risoluzione dei nomi e la portata del routing invece di fermarsi a un'icona connessa.

Interrogare l'archivio dei profili del dispositivo perché il test produca prove e non un'impressione.

Get-VpnConnection -AllUserConnection | Select-Object Name, ServerAddress, TunnelType, AuthenticationMethod, SplitTunneling
Get-VpnConnection -Name "Corp VPN" | Format-List
Test-NetConnection intranet.example.com -Port 443

Passare poi agli eventi che gli utenti incontrano davvero: un ripristino forzato della password, un certificato rinnovato, un aggiornamento del client spinto e una rete che nessuno nel pilota ha mai usato. Ognuno dovrebbe funzionare o fallire come descritto nelle istruzioni. Provare anche una rete che blocca la porta VPN, perché il primo tentativo su un Wi-Fi d'albergo è dove un successo a casa smette di aiutare. Annotare la versione del client e la build del sistema accanto a ogni risultato, dato che il prossimo rapporto arriverà senza.

Mantenere la consegna all'utente in quattro righe: il nome della connessione, l'accesso atteso, la risorsa che dimostra il successo e dove inviare il testo dell'errore. A nessuno dovrebbe essere chiesta una password o una chiave esportata per dimostrare un guasto. L'architettura, l'interno del profilo e la procedura di ripristino appartengono al runbook dell'amministratore, archiviato accanto alla versione del client con cui sono stati provati.