VPN-profiel word nie op macOS ingevoer nie: lees eers die vrag

Wanneer 'n profiel op een Mac sonder probleme installeer en op 'n ander geweier word, is die netwerk nog nie bereik nie, dus verdien sertifikate, poorte en wagwoorde geen skuld nie. Die installeerder het by 'n vrag gestop wat hy nie sou aanvaar nie, en hy teken gewoonlik aan watter een. Dit laat die profiellêer en alles wat dit geskep het as die enigste sinvolle plekke om te werk, en dit maak die uitvee van instellings op die kliënt 'n manier om bewyse te vernietig eerder as 'n herstel.

Lees die profiel eerder as om die Mac te herstel

Eksporteer die .mobileconfig en kyk wat dit werklik dra voordat jy aan die kliënt raak:

plutil -p profile.mobileconfig | head -60

'n VPN-profiel is eintlik twee vragte wat verskillende take doen: com.apple.vpn.managed hou die verbinding, en com.apple.dnsSettings.managed hou die oplosser-konfigurasie. Die installasie stop by die eerste vrag wat die installeerder verwerp, en die verwerping beland in die stelsellog met daardie vrag by die naam, so die log sê vir jou watter afdeling om oop te maak. Hou 'n kopie van die laaste profiel wat wel ingevoer is, want daardie lêer is die basis waarteen jou diff gemeet word.

Wat die generator stilweg bygevoeg het

Apple Configurator 2.15 bou 7A23 het die volgende blok in sy DNS-vrag uitgestuur:

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

Op macOS 12.1 is profiele wat deur daardie bou geskryf is, by invoer verwerp. 'n Verbinding wat met Configurator 2.11.1 gemaak is, het sonder klagte ingegaan, want daardie weergawe het die sleutel glad nie geskryf nie. Verwyder die hele DNS-woordeboek of net die aanstootlike sleutel, stoor dit weer en probeer dan op dieselfde masjien voordat jy enigiets anders verander. Daardie enkele wysiging is gewoonlik die hele herstel.

Die hulpmiddel het 'n valstrik wat die moeite werd is om te ken voordat jy dit vertrou. Nadat die sleutel verwyder is, het die stoor van dieselfde verbinding dit nie teruggesit nie, en dit het eers weer verskyn toe 'n verbinding van nuuts af geskep is. Behandel elke nuut geskepte profiel as verdag en ondersoek dit, veral wanneer 'n hele klomp verbindings in een sitting gemaak is.

Die MDM-roete faal op 'n ander plek

'n Bestuursdiens wat dieselfde profiel stoot, kan op 'n ander plek faal: die kliënt kla dat daar glad geen VPN-diens geskep is nie. Die gerapporteerde geval het 'n vrag gehad wat vir sertifikaat-verifikasie opgestel is, maar tog 'n wagwoordveld geëis het; deur dit met 'n plekhouer te vul, kon die profiel toegepas word, en niks het ooit daardie waarde vir verifikasie gebruik nie.

As jy daardie roete volg, stoor 'n dummy-string en nooit 'n lewende geloofsbrief nie, en hou die regte geheim uit die profiel se liggaam. 'n Profiel wat 'n werkende wagwoord dra, word 'n lêer wat soos 'n sleutel beskerm moet word, en dit is 'n aansienlik groter probleem as die mislukte invoer waarmee jy begin het. Besluit wie daardie plekhouer besit voordat die profiel versprei word, sodat niemand dit later as 'n waarde aansien wat geroteer moet word nie. Om te dokumenteer waarom dit bestaan neem een reël en spaar 'n rusie oor ses maande.

Bevestig dat die profiel werklik geland het

'n Suksesvolle invoer is nie 'n werkende diens nie, so kyk in hierdie volgorde:

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

Die eerste opdrag lys geïnstalleerde vragte; die tweede sê of daar hoegenaamd 'n VPN-diens bestaan. Die laaste een, uitgevoer nadat jy verbind het, wys watter oplosser die stelsel werklik gaan gebruik. Lees hulle in daardie volgorde en stop waar die ketting breek, want 'n ontbrekende diens maak enige oplosser-vraag betekenisloos. 'n Profiel kan as geïnstalleer gelys wees en tog niks bruikbaar besit nie, en dit is presies die toestand wat hierdie reeks bedoel is om te ontbloot.

Sou die tonnel opkom terwyl 'n diensinskrywing steeds geen bruikbare naam het nie, dan het die vertoonnaam-veld in die uitvoer verlore gegaan, en die oplossing is 'n herskep profiel eerder as 'n hernoeming op die kliënt. As die oplosser aanhou na die plaaslike een wys, is die DNS-vrag meer deeglik verwyder as wat jy bedoel het.

Doen die uitrol in fases, een Mac op 'n slag

Installeer op een bestuurde Mac met dieselfde bedryfstelselbou, en kyk dan drie dinge afsonderlik na: die diens verskyn, die oplosser verander, en 'n enkele werklike interne versoek slaag. Eers nadat al drie waar is, behoort die omvang te verbreed.

Dit is drie verskillende resultate wat op drie verskillende maniere misluk, en dit is wat een toetsmasjien die tien minute werd maak. 'n Profiel wat invoer is nie 'n profiel wat werk nie, en die fase-een-masjien vang albei soorte mislukking voordat die res van die vloot enigeen sien.