Avviare una VPN Mac salvata dal terminale con scutil --nc

Avete un servizio VPN salvato in Impostazioni di Sistema e volete che il terminale lo avvii. Su macOS il percorso supportato è scutil --nc, ma solo per i servizi posseduti dal gestore delle connessioni di rete del sistema stesso. La barra dei menu non è l’API: i client di terze parti di solito hanno la propria automazione, e un profilo inviato da un servizio di gestione può rifiutare un avvio locale. Questa è la lista di controllo che seguo: trovate il servizio esatto, leggete il suo stato, avviatelo, attendete che lo stato cambi, poi dimostrate che il traffico usa davvero il tunnel. Fermatevi al primo passo che non torna, perché ogni comando successivo presuppone che il precedente sia riuscito.

Trovate il servizio prima di provare ad avviarlo

Iniziate dall’inventario invece che dal nome del profilo che ricordate:

scutil --nc help
scutil --nc list

Ogni riga abbina uno stato a un identificatore di servizio, un tipo e un nome visualizzato. L’identificatore è il valore su cui scrivere script, perché i nomi visualizzati si ripetono e possono essere modificati. Il manuale scutil di Apple documenta la modalità connessione di rete, mentre il --nc help installato è l’elenco autorevole dei sottocomandi su quel Mac; non date per scontato che un flag di una guida più vecchia esista ancora nella vostra versione di macOS.

Un elenco vuoto è un risultato, non un errore. Un servizio creato da un client del fornitore o da un profilo di gestione può essere attivo mentre è invisibile qui, o visibile con un tipo che il controller nativo non può pilotare. In quel caso, usate lo strumento del fornitore o la documentazione del profilo. Creare un profilo nativo parallelo solo per avere qualcosa da avviare è un cattivo affare.

Leggete lo stato attuale e confermate il selettore

Interrogate il servizio prima di avviarlo, così sapete cosa dovrebbe cambiare un avvio riuscito:

scutil --nc status "Office VPN"

Se due servizi condividono un nome visualizzato, il nome è ambiguo. Passate invece l’identificatore; il comando accetta entrambi, ma solo l’identificatore garantisce di selezionare un solo servizio. Verificate che la parola di stato sia una che riconoscete — di solito Connected, Disconnected, Connecting o Disconnecting — prima di analizzarla in uno script. Verificate anche se il profilo è gestito, perché una configurazione bloccata può accettare il comando e comunque ignorarlo o chiedere conferma.

Questa chiamata di stato è economica, quindi usatela come guardia nell’automazione: avviate solo quando lo stato è Disconnected, e non trattate Connecting come un errore. Se il servizio è già Connected, saltate l’avvio invece di interrompere un tunnel funzionante.

Avviate la connessione e attendete che lo stato si stabilizzi

La richiesta di avvio è asincrona. Il comando torna quando la richiesta è stata accettata, non quando l’autenticazione è finita o le rotte sono installate. Eseguitelo, poi interrogate lo stato con un’attesa limitata e uscite se il servizio ricade su Disconnected:

scutil --nc start "Office VPN"
n=0
while [ "$n" -lt 30 ]; do
  state=$(scutil --nc status "Office VPN" | head -n 1)
  [ "$state" = "Connected" ] && break
  [ "$state" = "Disconnected" ] && { echo "start failed"; exit 1; }
  sleep 2
  n=$((n + 1))
done

Uno stato Connecting che non si risolve mai di solito indica credenziali, MFA o il server, non scutil. Il comando non può fornire un accesso interattivo, quindi un profilo che aspetta un token o una chiave hardware resterà in Connecting e alla fine ricadrà. Leggete la parola di stato prima di aggiungere tentativi; un ciclo contro un prompt di autenticazione non può riuscire.

Non trattate il codice di uscita della shell come disponibilità. Il segnale utile è la stringa di stato, seguita dalla prova che il tunnel trasporta traffico. Un comando di avvio che torna in silenzio può comunque lasciarvi con una connessione che non si autentica mai.

Dimostrate che il tunnel trasporta traffico, non solo che dice Connected

Connected descrive la connessione, non la decisione di routing. I servizi nativi PPP e IKEv2 creano un’interfaccia ppp o utun e installano rotte, mentre un tunnel diviso lascia deliberatamente intatta la rotta predefinita. Ispezionate le interfacce ed entrambe le famiglie di indirizzi:

ifconfig -l
netstat -rn -f inet
netstat -rn -f inet6
scutil --dns

Trovate l’interfaccia creata dal servizio invece di indovinare un numero, poi chiedete alla tabella di routing quale interfaccia usa una destinazione specifica: route -n get 10.0.0.10, sostituendolo con un host interno. Se riporta l’interfaccia fisica, il tunnel è attivo ma non trasporta quel flusso. Controllate le rotte del tunnel diviso, l’ordine dei resolver e qualsiasi regola locale del firewall che consente l’interfaccia del tunnel ma non il processo.

La risoluzione dei nomi è il falso negativo abituale. I nomi interni possono risolversi tramite il resolver sbagliato mentre il tunnel è perfettamente sano, il che sembra un guasto VPN e non lo è. scutil --dns mostra l’ordine che macOS userà; dopo un cambio di resolver, svuotate la cache con dscacheutil -flushcache e sudo killall -HUP mDNSResponder.

Tenete credenziali e privilegi fuori dalla riga di comando

Non mettete mai una password, una chiave precondivisa o un token negli argomenti. Gli argomenti sono visibili negli elenchi dei processi e finiscono nella cronologia della shell, e una trascrizione di supporto copiata può divulgarli. La gestione delle credenziali propria del profilo — che sia un elemento Keychain, un prompt di sistema o il flusso di autenticazione del client — è il posto per i segreti.

Eseguire il comando con sudo non rende un accesso interattivo non presidiato. Cambia l’utente effettivo, non la disponibilità di un prompt GUI, di un token hardware o del portachiavi di accesso. Un LaunchAgent può avviare un servizio dopo che l’utente ha effettuato l’accesso e il portachiavi è sbloccato; un LaunchDaemon di solito non raggiunge quelle parti della sessione utente. Se un’organizzazione gestisce il servizio, le sue regole del ciclo di vita prevalgono su qualsiasi script locale.

Fermate il servizio e verificate che sia rimasto fermo

Fermate con lo stesso selettore usato per avviare, poi rileggete lo stato invece di presumere che il tunnel sia sparito:

scutil --nc stop "Office VPN"
scutil --nc status "Office VPN"

Un arresto che torna a Disconnected lascia comunque una cosa da controllare: se il profilo è impostato per connettersi su richiesta, il che può riportarlo su senza il vostro script. Se un altro client possiede rotte sullo stesso Mac, quelle rotte possono sopravvivere a un arresto nativo. Ricontrollate la rotta prima di concludere che la macchina è fuori dalla VPN.

Per un wrapper che eseguite a mano, mantenete l’ordine fisso: elenco, stato, avvio, interrogazione, test della rotta, arresto, verifica. Non analizzate il nome descrittivo da un output libero quando l’identificatore è disponibile, e non trattate l’uscita del comando di avvio come disponibilità. Il gestore delle connessioni riporta lo stato; la vostra prova è lo stato più una rotta che punta al tunnel.