Un profilo VPN non si importa su macOS: leggete prima il payload

Quando un profilo si installa senza problemi su un Mac e viene rifiutato su un altro, la rete non è ancora stata raggiunta, quindi certificati, gateway e password non meritano alcuna colpa. L’installer si è fermato su un payload che non intendeva accettare, e di solito registra quale. Questo lascia il file del profilo e tutto ciò che lo ha generato come gli unici luoghi sensati dove lavorare, e rende la cancellazione delle impostazioni sul client un modo di distruggere le prove invece di una riparazione.

Leggete il profilo invece di reimpostare il Mac

Esportate il .mobileconfig e guardate cosa contiene davvero prima di toccare il client:

plutil -p profile.mobileconfig | head -60

Un profilo VPN è in realtà due payload con compiti diversi: com.apple.vpn.managed contiene la connessione e com.apple.dnsSettings.managed contiene la configurazione del resolver. L’installazione si ferma al primo payload che l’installer rifiuta, e il rifiuto finisce nel registro di sistema con il nome di quel payload, quindi è il registro a dirvi quale sezione aprire. Tenete una copia dell’ultimo profilo che è stato importato davvero, perché quel file è la base su cui viene misurata la vostra differenza.

Cosa ha aggiunto il generatore in silenzio

Apple Configurator 2.15, build 7A23, ha emesso il seguente blocco dentro il suo payload DNS:

<key>DNS</key>
<dict>
  <key>SupplementalMatchDomainsNoSearch</key>
  <integer>0</integer>
</dict>

Su macOS 12.1, i profili scritti da quella build sono stati rifiutati all’importazione. Una connessione creata con Configurator 2.11.1 è entrata senza lamentarsi, perché quella versione non scriveva affatto la chiave. Rimuovete l’intero dizionario DNS o solo la chiave incriminata, salvatelo di nuovo e poi riprovate sulla stessa macchina prima di cambiare qualsiasi altra cosa. Di solito quella singola modifica è tutta la riparazione.

Lo strumento ha una trappola che vale la pena conoscere prima di fidarvi. Una volta cancellata la chiave, salvare la stessa connessione non l’ha rimessa, ed è ricomparsa solo quando è stata creata una connessione da zero. Trattate ogni profilo appena generato come sospetto e ispezionatelo, soprattutto quando è stata creata un’intera serie di connessioni in una sola sessione.

La via MDM fallisce altrove

Un servizio di gestione che spinge lo stesso profilo può fallire in un altro punto: il client si lamenta che non è stato creato alcun servizio VPN. Nel caso segnalato un payload configurato per l’autenticazione con certificato richiedeva comunque un campo password; riempirlo con un segnaposto ha permesso di applicare il profilo, e nulla ha mai usato quel valore per autenticare.

Se seguite quella via, memorizzate una stringa fittizia e mai una credenziale reale, e tenete il vero segreto fuori dal corpo del profilo. Un profilo che porta una password funzionante diventa un file da proteggere come una chiave, e questo è un problema molto più grande dell’importazione fallita con cui avete iniziato. Decidete a chi appartiene quel segnaposto prima che il profilo sia distribuito, perché nessuno in seguito lo scambi per un valore che vale la pena ruotare. Documentare perché esiste costa una riga e risparmia una discussione fra sei mesi.

Verificate che il profilo sia davvero atterrato

Un’importazione riuscita non è un servizio funzionante, quindi controllate in quest’ordine:

profiles show -type configuration
scutil --nc list
scutil --nc start "Your VPN Service"
scutil --nc status "Your VPN Service"
scutil --dns | head -20

Il primo comando elenca i payload installati; il secondo dice se esiste del tutto un servizio VPN. L’ultimo, eseguito dopo la connessione, mostra il resolver che il sistema userà davvero. Leggeteli in quest’ordine e fermatevi dove la catena si spezza, perché un servizio mancante rende priva di senso qualsiasi domanda sul resolver. Un profilo può risultare installato e non possedere nulla di utilizzabile, ed è esattamente lo stato che questa sequenza è progettata per esporre.

Se il tunnel si alza mentre una voce di servizio non ha ancora un nome utilizzabile, il campo del nome visualizzato è andato perso nell’esportazione, e la cura è un profilo rigenerato invece di una rinomina sul client. Se il resolver continua a puntare a quello locale, il payload DNS è stato rimosso più a fondo di quanto intendevate.

Distribuite per fasi, un Mac alla volta

Installate su un Mac gestito che esegue la stessa build del sistema, poi verificate tre cose separatamente: il servizio compare, il resolver cambia e una vera richiesta interna riesce. Solo dopo tutte e tre l’ambito va allargato.

Sono tre risultati diversi che falliscono in tre modi diversi, ed è questo che rende una macchina di prova degna di quei dieci minuti. Un profilo che si importa non è un profilo che funziona, e la macchina della prima fase intercetta entrambi i tipi di guasto prima che il resto della flotta ne veda uno.