VPN-profiel wordt niet geïmporteerd op macOS: lees eerst de payload

Wanneer een profiel op de ene Mac probleemloos installeert en op de andere wordt geweigerd, is het netwerk nog niet bereikt, dus certificaten, gateways en wachtwoorden verdienen geen verwijt. De installer stopte bij een payload die hij niet wilde accepteren, en noteert meestal welke. Dat laat het profielbestand en alles wat het heeft gegenereerd als de enige verstandige werkplekken, en het wissen van instellingen op de client wordt een manier om bewijs te vernietigen in plaats van een reparatie.

Lees het profiel in plaats van de Mac te resetten

Exporteer de .mobileconfig en kijk wat er werkelijk in staat voordat u de client aanraakt:

plutil -p profile.mobileconfig | head -60

Een VPN-profiel bestaat eigenlijk uit twee payloads met verschillende taken: com.apple.vpn.managed bevat de verbinding, en com.apple.dnsSettings.managed bevat de resolverconfiguratie. De installatie stopt bij de eerste payload die de installer weigert, en de weigering belandt met de naam van die payload in het systeemlog, dus het log vertelt u welke sectie u moet openen. Bewaar een kopie van het laatste profiel dat wel is geïmporteerd, want dat bestand is de basis waartegen uw verschil wordt gemeten.

Wat de generator stilletjes toevoegde

Apple Configurator 2.15, build 7A23, heeft het volgende blok in zijn DNS-payload uitgevoerd:

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

Op macOS 12.1 werden profielen die door die build waren geschreven bij import geweigerd. Een verbinding gemaakt met Configurator 2.11.1 kwam zonder klachten binnen, omdat die release de sleutel helemaal niet schreef. Verwijder het hele DNS-woordenboek of alleen de problematische sleutel, sla het opnieuw op en probeer het daarna op dezelfde machine voordat u iets anders wijzigt. Meestal is die ene aanpassing de hele reparatie.

De tool heeft een valkuil die u moet kennen voordat u erop vertrouwt. Nadat de sleutel was verwijderd, zette het opslaan van dezelfde verbinding hem niet terug, en hij verscheen pas weer toen er een verbinding vanaf nul werd gemaakt. Behandel elk vers gegenereerd profiel als verdacht en inspecteer het, vooral wanneer een hele reeks verbindingen in één sessie is gemaakt.

Het MDM-pad faalt ergens anders

Een beheerdienst die hetzelfde profiel pusht, kan op een ander punt falen: de client klaagt dat er helemaal geen VPN-dienst is aangemaakt. In het gemelde geval eiste een payload die voor certificaatauthenticatie was geconfigureerd toch een wachtwoordveld; het vullen met een plaatsaanduiding liet het profiel toepassen, en niets gebruikte die waarde ooit om te authenticeren.

Als u dat pad neemt, sla dan een dummy-tekenreeks op en nooit een echte referentie, en houd het echte geheim buiten de profielinhoud. Een profiel met een werkend wachtwoord wordt een bestand dat als een sleutel moet worden beschermd, en dat is een aanzienlijk groter probleem dan de mislukte import waarmee u begon. Bepaal wie eigenaar is van die plaatsaanduiding voordat het profiel wordt verspreid, zodat niemand hem later voor een waarde aanziet die het waard is om te roteren. Documenteren waarom hij bestaat kost één regel en bespaart over zes maanden een discussie.

Controleer of het profiel echt is aangekomen

Een geslaagde import is geen werkende dienst, dus controleer in deze volgorde:

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

De eerste opdracht somt geïnstalleerde payloads op; de tweede zegt of er überhaupt een VPN-dienst bestaat. De laatste, uitgevoerd na het verbinden, toont de resolver die het systeem werkelijk zal gebruiken. Lees ze in die volgorde en stop waar de keten breekt, want een ontbrekende dienst maakt elke vraag over de resolver zinloos. Een profiel kan als geïnstalleerd staan en toch niets bruikbaars bezitten, en dat is precies de toestand die deze reeks moet blootleggen.

Als de tunnel omhoog komt terwijl een dienstvermelding nog geen bruikbare naam heeft, is het veld voor de weergavenaam bij de export verloren gegaan, en de remedie is een opnieuw gegenereerd profiel in plaats van een naamswijziging op de client. Als de resolver naar de lokale blijft wijzen, is de DNS-payload grondiger verwijderd dan u bedoelde.

Rol uit in fasen, één Mac per keer

Installeer op één beheerde Mac met dezelfde OS-build, en controleer daarna drie dingen apart: de dienst verschijnt, de resolver verandert en één echte interne aanvraag slaagt. Pas daarna mag de omvang groeien.

Dat zijn drie verschillende resultaten die op drie verschillende manieren falen, en dat is wat één testmachine de tien minuten waard maakt. Een profiel dat importeert is geen profiel dat werkt, en de machine van de eerste fase vangt beide soorten fouten voordat de rest van de vloot er een ziet.