VPN-profil let seg ikkje importere på macOS: les payloaden først
Ein profil som blir avvist på éin Mac og godteken på ein annan, er som regel eit payload-problem. Samanlikn XML-en, sjekk kva generatoren la til, og verifiser deretter tenesta.
Når ein profil blir installert reint på éin Mac og avvist på ein annan, er nettet enno ikkje nådd, så sertifikat, gatewayar og passord fortener inga skulding. Installatøren stoppa på ein payload han ikkje ville godta, og han registrerer vanlegvis kven. Det lèt profilfila og alt som genererte ho stå att som dei einaste fornuftige arbeidsstadene, og gjer sletting av innstillingar på klienten til ein måte å øydeleggje prov på i staden for ein reparasjon.
Les profilen i staden for å nullstille Mac-en
Eksporter .mobileconfig og sjå kva ho faktisk inneheld før du rører klienten:
plutil -p profile.mobileconfig | head -60
Ein VPN-profil er eigentleg to payloadar med ulike oppgåver: com.apple.vpn.managed held sambandet, og com.apple.dnsSettings.managed held resolver-konfigurasjonen. Installasjonen stoppar på den første payloaden installatøren avviser, og avvisinga hamnar i systemloggen med den payloaden namngjeven, så loggen er det som fortel deg kva seksjon du skal opne. Ta vare på ein kopi av den siste profilen som faktisk let seg importere, fordi den fila er grunnlaget skilnaden din blir målt mot.
Kva generatoren stille la til
Apple Configurator 2.15, build 7A23, sende ut følgjande blokk inne i DNS-payloaden sin:
<key>DNS</key>
<dict>
<key>SupplementalMatchDomainsNoSearch</key>
<integer>0</integer>
</dict>
På macOS 12.1 vart profilar skrivne av den builden avviste ved import. Eit samband laga med Configurator 2.11.1 gjekk inn utan klage, fordi den utgåva ikkje skreiv nøkkelen i det heile. Fjern heile DNS-ordboka eller berre den problematiske nøkkelen, lagre på nytt, og prøv så igjen på same maskin før du endrar noko anna. Den eine rettinga er vanlegvis heile reparasjonen.
Verktøyet har ei felle det er verd å kjenne før du stolar på det. Etter at nøkkelen var sletta, sette lagring av same samband han ikkje tilbake, og han dukka berre opp igjen då eit samband vart oppretta frå botnen. Behandle kvar nygenerert profil som mistenkeleg og gransk han, særleg når ein heil haug samband vart laga i éi økt.
MDM-vegen feilar ein annan stad
Ein administrasjonsteneste som dyttar same profil kan feile ein annan stad: klienten klagar over at det ikkje vart oppretta noka VPN-teneste i det heile. I det rapporterte tilfellet hadde ein payload konfigurert for sertifikatautentisering likevel krav om eit passordfelt; å fylle det med ein plasshaldar lét profilen bli brukt, og ingenting brukte nokon gong den verdien til å autentisere.
Viss du går den vegen, lagre ein dummy-streng og aldri ein levande legitimasjon, og hald den ekte hemmelegheita utanfor sjølve profilen. Ein profil med eit fungerande passord blir ei fil som må vernast som ein nøkkel, og det er eit monaleg større problem enn den mislukka importen du starta med. Avgjer kven som eig den plasshaldaren før profilen blir distribuert, så ingen seinare forvekslar han med ein verdi som er verd å rotere. Å dokumentere kvifor han finst tek éi linje og sparer ein diskusjon om seks månader.
Stadfest at profilen faktisk landa
Ein vellukka import er ikkje ei teneste som verkar, så kontroller i denne rekkjefølgja:
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 listar installerte payloadar; den andre seier om det finst ei VPN-teneste i det heile. Den siste, køyrd etter tilkopling, viser resolveren systemet faktisk vil bruke. Les dei i den rekkjefølgja og stopp der kjeda brister, fordi ei manglande teneste gjer kvart spørsmål om resolveren meiningslaust. Ein profil kan stå oppført som installert og likevel ikkje eige noko brukbart, og det er nettopp den tilstanden denne sekvensen er laga for å avdekkje.
Skulle tunnelen kome opp medan ei tenesteføring enno ikkje har eit brukbart namn, gjekk feltet for visingsnamn tapt i eksporten, og kuren er ein regenerert profil i staden for eit namnebyte på klienten. Viss resolveren held fram med å peike på den lokale, er DNS-payloaden fjerna grundigare enn du hadde tenkt.
Rull ut i trinn, éin Mac om gongen
Installer på éin administrert Mac med same OS-build, og kontroller deretter tre ting kvar for seg: tenesta dukkar opp, resolveren blir endra, og éin ekte intern førespurnad lukkast. Først når alle tre stemmer, bør omfanget utvidast.
Det er tre ulike resultat som feilar på tre ulike måtar, og det er det som gjer éi testmaskin verd dei ti minutta. Ein profil som let seg importere er ikkje ein profil som verkar, og maskinen i første trinn fangar begge slag feil før resten av flåten ser nokon av dei.