VPN-profil vil ikke importeres på macOS: læs payloaden først

Når en profil installeres problemfrit på en Mac og afvises på en anden, er netværket endnu ikke nået, så certifikater, gateways og adgangskoder fortjener ingen skyld. Installationsprogrammet stoppede ved en payload, det ikke ville acceptere, og det registrerer normalt hvilken. Det efterlader profilfilen og alt, hvad der genererede den, som de eneste fornuftige steder at arbejde, og det gør sletning af indstillinger på klienten til en måde at ødelægge beviser på snarere end en reparation.

Læs profilen i stedet for at nulstille Mac’en

Eksportér .mobileconfig og se, hvad den faktisk indeholder, før du rører klienten:

plutil -p profile.mobileconfig | head -60

En VPN-profil er i virkeligheden to payloads med forskellige opgaver: com.apple.vpn.managed holder forbindelsen, og com.apple.dnsSettings.managed holder resolver-konfigurationen. Installationen stopper ved den første payload, som installationsprogrammet afviser, og afvisningen havner i systemloggen med den payload navngivet, så loggen er det, der fortæller dig, hvilken sektion du skal åbne. Gem en kopi af den seneste profil, der faktisk blev importeret, fordi den fil er det grundlag, din diff måles imod.

Hvad generatoren stille tilføjede

Apple Configurator 2.15 build 7A23 udsendte følgende blok inde i sin DNS-payload:

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

På macOS 12.1 blev profiler skrevet af det build afvist ved import. En forbindelse oprettet med Configurator 2.11.1 gik ind uden klage, fordi den udgivelse slet ikke skrev nøglen. Fjern hele DNS-ordbogen eller blot den problematiske nøgle, gem den igen, og prøv så igen på samme maskine, før du ændrer noget andet. Den ene rettelse er normalt hele reparationen.

Værktøjet har en fælde, som er værd at kende, før du stoler på det. Efter nøglen var slettet, satte en lagring af den samme forbindelse den ikke tilbage, og den dukkede kun op igen, når en forbindelse blev oprettet fra bunden. Behandl enhver nygenereret profil som mistænkelig og undersøg den, især når en hel stak forbindelser blev lavet i én arbejdsgang.

MDM-vejen fejler et andet sted

En styringstjeneste, der skubber den samme profil, kan fejle et andet sted: klienten klager over, at der slet ikke blev oprettet nogen VPN-tjeneste. I det rapporterede tilfælde havde en payload konfigureret certifikatgodkendelse, men krævede alligevel et adgangskodefelt; at udfylde det med en pladsholder lod profilen blive anvendt, og intet brugte nogensinde den værdi til godkendelse.

Hvis du tager den vej, skal du gemme en dummy-streng og aldrig en levende adgangskode, og holde den rigtige hemmelighed ude af profilens krop. En profil med en fungerende adgangskode bliver en fil, der skal beskyttes som en nøgle, og det er et betydeligt større problem end den mislykkede import, du startede med. Beslut, hvem der ejer den pladsholder, før profilen distribueres, så ingen senere forveksler den med en værdi, der er værd at rotere. At dokumentere, hvorfor den findes, tager én linje og sparer en diskussion om seks måneder.

Bekræft, at profilen faktisk landede

En vellykket import er ikke en fungerende tjeneste, så kontrollér i denne rækkefølge:

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 kommando viser installerede payloads; den anden siger, om der overhovedet findes en VPN-tjeneste. Den sidste, kørt efter forbindelse, viser den resolver, systemet faktisk vil bruge. Læs dem i den rækkefølge, og stop hvor kæden brister, fordi en manglende tjeneste gør ethvert spørgsmål om resolveren meningsløst. En profil kan være listet som installeret og alligevel ikke eje noget brugbart, og det er præcis den tilstand, denne sekvens er beregnet til at afdække.

Skulle tunnelen komme op, mens en tjenestepost stadig ikke har et brugbart navn, gik visningsnavnefeltet tabt i eksporten, og kuren er en regenereret profil snarere end en omdøbning på klienten. Hvis resolveren bliver ved med at pege på den lokale, er DNS-payloaden fjernet mere grundigt, end du havde tænkt.

Udrul i etaper, én Mac ad gangen

Installér på én administreret Mac med det samme OS-build, og kontrollér derefter tre ting hver for sig: tjenesten vises, resolveren ændres, og én rigtig intern anmodning lykkes. Først når alle tre er opfyldt, bør omfanget udvides.

Det er tre forskellige resultater, der fejler på tre forskellige måder, og det er det, der gør én testmaskine de ti minutter værd. En profil, der importeres, er ikke en profil, der virker, og maskinen i første etape fanger begge slags fejl, før resten af flåden ser nogen af dem.