VPN-profil lar seg ikke importere på macOS: les payloaden først

Når en profil installeres rent på én Mac og avvises på en annen, er nettverket ennå ikke nådd, så sertifikater, gateways og passord fortjener ingen skyld. Installatøren stoppet på en payload den ikke ville godta, og den registrerer vanligvis hvilken. Det etterlater profilfilen og alt som genererte den som de eneste fornuftige stedene å jobbe, og gjør sletting av innstillinger på klienten til en måte å ødelegge bevis på i stedet for en reparasjon.

Les profilen i stedet for å nullstille Mac-en

Eksporter .mobileconfig og se hva den faktisk inneholder før du rører klienten:

plutil -p profile.mobileconfig | head -60

En VPN-profil er egentlig to payloads med forskjellige oppgaver: com.apple.vpn.managed holder tilkoblingen, og com.apple.dnsSettings.managed holder resolver-konfigurasjonen. Installasjonen stopper på den første payloaden installatøren avviser, og avvisningen havner i systemloggen med den payloaden navngitt, så loggen er det som forteller deg hvilken seksjon du skal åpne. Ta vare på en kopi av den siste profilen som faktisk lot seg importere, fordi den filen er grunnlaget forskjellen din måles mot.

Hva generatoren stille la til

Apple Configurator 2.15, build 7A23, sendte ut følgende blokk inne i DNS-payloaden sin:

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

På macOS 12.1 ble profiler skrevet av det buildet avvist ved import. En tilkobling laget med Configurator 2.11.1 gikk inn uten klage, fordi den utgivelsen ikke skrev nøkkelen i det hele tatt. Fjern hele DNS-ordboken eller bare den problematiske nøkkelen, lagre på nytt, og prøv så igjen på samme maskin før du endrer noe annet. Den ene rettelsen er vanligvis hele reparasjonen.

Verktøyet har en felle det er verdt å kjenne før du stoler på det. Etter at nøkkelen var slettet, satte lagring av samme tilkobling den ikke tilbake, og den dukket bare opp igjen da en tilkobling ble opprettet fra bunnen. Behandle hver nygenerert profil som mistenkelig og undersøk den, spesielt når en hel haug tilkoblinger ble laget i én økt.

MDM-veien feiler et annet sted

En administrasjonstjeneste som dytter samme profil kan feile et annet sted: klienten klager over at det ikke ble opprettet noen VPN-tjeneste i det hele tatt. I det rapporterte tilfellet hadde en payload konfigurert for sertifikatautentisering likevel krav om et passordfelt; å fylle det med en plassholder lot profilen bli brukt, og ingenting brukte noen gang den verdien til å autentisere.

Hvis du går den veien, lagre en dummy-streng og aldri en levende legitimasjon, og hold den ekte hemmeligheten utenfor selve profilen. En profil med et fungerende passord blir en fil som må beskyttes som en nøkkel, og det er et betydelig større problem enn den mislykkede importen du startet med. Bestem hvem som eier den plassholderen før profilen distribueres, så ingen senere forveksler den med en verdi som er verdt å rotere. Å dokumentere hvorfor den finnes tar én linje og sparer en diskusjon om seks måneder.

Bekreft at profilen faktisk landet

En vellykket import er ikke en tjeneste som virker, så kontroller i denne rekkefølgen:

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

Den første kommandoen lister installerte payloads; den andre sier om det finnes en VPN-tjeneste i det hele tatt. Den siste, kjørt etter tilkobling, viser resolveren systemet faktisk vil bruke. Les dem i den rekkefølgen og stopp der kjeden brister, fordi en manglende tjeneste gjør ethvert spørsmål om resolveren meningsløst. En profil kan være oppført som installert og likevel ikke eie noe brukbart, og det er nettopp den tilstanden denne sekvensen er laget for å avdekke.

Skulle tunnelen komme opp mens en tjenesteoppføring fortsatt ikke har et brukbart navn, gikk feltet for visningsnavn tapt i eksporten, og kuren er en regenerert profil i stedet for et navnebytte på klienten. Hvis resolveren fortsetter å peke på den lokale, er DNS-payloaden fjernet grundigere enn du hadde tenkt.

Rull ut i trinn, én Mac om gangen

Installer på én administrert Mac med samme OS-build, og kontroller deretter tre ting hver for seg: tjenesten dukker opp, resolveren endres, og én ekte intern forespørsel lykkes. Først når alle tre stemmer, bør omfanget utvides.

Det er tre forskjellige resultater som feiler på tre forskjellige måter, og det er det som gjør én testmaskin verdt de ti minuttene. En profil som lar seg importere er ikke en profil som virker, og maskinen i første trinn fanger begge typer feil før resten av flåten ser noen av dem.