Il tuo script avvia la VPN; non la fornisce

Scrivi uno script che esegue scutil --nc start con il nome della connessione, funziona sul tuo Mac e fallisce su ogni macchina appena installata dell'ufficio. Lo script non è rotto. Gli si chiede qualcosa che non è mai stato in grado di fare: avviare una connessione esistente non è la stessa operazione che crearne una.

Il provisioning e il controllo di sessione sono due lavori con due responsabili, e un flusso di lavoro che presume il contrario supererà ogni test sulla macchina dove è stato scritto.

Con cosa parla davvero il comando di avvio

Un comando di controllo di sessione si rivolge a una configurazione che esiste già ed è già approvata. Chiede al sistema di alzare quella connessione con nome, usando le impostazioni del server, i riferimenti di identità e la politica salvati in precedenza. Se questi non sono mai stati installati, non c'è nulla da avviare.

Per questo il guasto compare su hardware nuovo e non sul portatile dell'amministratore. Il portatile è stato approvvigionato mesi fa da una persona che da allora se n'è dimenticata. Pensa al comando di avvio come a un campanello che qualcuno ha cablato il trimestre scorso. Premere non è lo stesso che posare il cablaggio.

Tre responsabili di una configurazione VPN

Un profilo gestito dall'organizzazione proviene dalla gestione dei dispositivi. Il profilo porta gli indirizzi del server, la disposizione dell'autenticazione e la politica richiesta dall'organizzazione, e l'amministratore VPN è la persona che li fornisce. Uno script non dovrebbe ricostruire quelle impostazioni da un nome visualizzato trovato in un elenco.

Una configurazione VPN personale nativa viene creata tramite l'API Network Extension di Apple, che copre i protocolli IPsec e IKEv2 integrati. È un'interfaccia applicativa con un passo di salvataggio e un'approvazione dell'utente, non un comando shell che crea silenziosamente qualsiasi tipo di tunnel fornito da un venditore.

Un client di terze parti è un terzo caso con il proprio formato di importazione, il proprio strumento di gestione e spesso il proprio helper privilegiato. La sua sessione appartiene al processo di quel venditore. Trovare un servizio di sistema con un nome simile non è prova che un comando di sistema controlli il tunnel, e presumerlo produce script che sembrano funzionare finché il venditore non aggiorna il client.

Il provisioning nativo ha un salvataggio e un'approvazione

Il modello di Apple è carica, modifica, salva. Un'applicazione carica le preferenze esistenti prima del suo primo salvataggio dopo l'avvio, modifica la configurazione e poi la salva. Il salvataggio segnala un errore quando non riesce a persistere, e ignorare quel risultato trasforma un guasto di provisioning in un guasto di connessione tre passi dopo.

Il primo salvataggio richiede anche che l'utente approvi l'applicazione. È un confine di sicurezza deliberato, e significa che la prima esecuzione su un Mac nuovo è interattiva anche quando ogni connessione e disconnessione successiva può essere automatizzata. Pianifica la prima esecuzione come un compito umano con una persona presente. Automatizza la seconda esecuzione e le successive, e dillo nel runbook perché nessuno prometta l'impossibile. Un piano di distribuzione che promette una prima esecuzione del tutto incustodita promette qualcosa che la piattaforma non offre.

Apple raccomanda anche di validare la compatibilità del server con un profilo di configurazione prima di affidarsi all'API. Fare quel controllo per primo separa «il server non accetterà questo client» da «il client non ha mai salvato le impostazioni», che sono ticket diversi per team diversi.

Cosa può presumere un comando di avvio ripetibile

Dopo il provisioning, uno script può puntare con sicurezza alla connessione esistente tramite l'interfaccia del suo proprietario. Dagli l'identità stabile della connessione più l'azione che vuoi, e nient'altro. Non dovrebbe leggere un percorso di preferenze indovinato, né presumere che il nome mostrato nel menu sia unico in tutto il sistema.

Per le connessioni native, una richiesta di sessione con nome come scutil --nc start è un'operazione di controllo. Non installa impostazioni del server, non importa credenziali e non esegue l'autorizzazione del primo salvataggio. Trattala come l'ultimo passo di una catena, mai come l'intera catena.

Tieni i segreti fuori dagli argomenti della riga di comando e fuori dall'output diagnostico ordinario. Qualunque meccanismo di identità abbia scelto la distribuzione, è quello su cui deve basarsi il comando di avvio, e una password incollata nella cronologia della shell è un rilievo in qualsiasi revisione.

Due controlli di accettazione

Il primo controllo è il provisioning: prendi un Mac appena installato e dimostra che la configurazione è presente, appartiene al gestore corretto ed è pienamente approvata. Fallo prima di testare la connettività, perché un test di connessione su una macchina non approvvigionata non dimostra nulla sullo script.

Il secondo controllo è la sessione: connetti, raggiungi la risorsa autorizzata e disconnetti in modo pulito. Ora ogni guasto ha un responsabile, ed è il beneficio pratico di separare i due lavori. Un profilo mancante è un problema di consegna, un errore di salvataggio è un problema di approvazione, un accesso rifiutato è un problema di autenticazione, e un timeout dopo un avvio riuscito è il livello di sessione. Nessuno di questi è «lo script è rotto».