VPN-Profil lässt sich unter macOS nicht importieren: zuerst die Payload lesen

Ein Profil, das auf einem Mac abgelehnt und auf einem anderen akzeptiert wird, ist meist ein Payload-Problem. Vergleichen Sie das XML, prüfen Sie, was der Generator hinzugefügt hat, und überprüfen Sie dann den Dienst.

Wenn ein Profil auf einem Mac sauber installiert und auf einem anderen abgelehnt wird, wurde das Netzwerk noch gar nicht erreicht, also trifft Zertifikate, Gateways und Kennwörter keine Schuld. Der Installer blieb an einer Payload stehen, die er nicht akzeptieren wollte, und vermerkt normalerweise, welche. Damit bleiben die Profildatei und alles, was sie erzeugt hat, als einzige sinnvolle Arbeitsplätze übrig, und das Löschen der Einstellungen auf dem Client wird zu einer Art der Beweisvernichtung statt zu einer Reparatur.

Lesen Sie das Profil, statt den Mac zurückzusetzen

Exportieren Sie die .mobileconfig und sehen Sie sich an, was sie tatsächlich enthält, bevor Sie den Client anfassen:

plutil -p profile.mobileconfig | head -60

Ein VPN-Profil besteht eigentlich aus zwei Payloads mit unterschiedlichen Aufgaben: com.apple.vpn.managed enthält die Verbindung, und com.apple.dnsSettings.managed enthält die Resolver-Konfiguration. Die Installation stoppt bei der ersten Payload, die der Installer ablehnt, und die Ablehnung landet mit dem Namen dieser Payload im Systemprotokoll, also sagt Ihnen das Protokoll, welchen Abschnitt Sie öffnen müssen. Heben Sie eine Kopie des letzten Profils auf, das sich importieren ließ, denn diese Datei ist die Basis, gegen die Ihr Diff gemessen wird.

Was der Generator stillschweigend hinzufügte

Apple Configurator 2.15, Build 7A23, hat folgenden Block in seine DNS-Payload geschrieben:

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

Unter macOS 12.1 wurden Profile, die dieser Build schrieb, beim Import abgelehnt. Eine Verbindung, die mit Configurator 2.11.1 erstellt wurde, ging ohne Beanstandung durch, weil diese Version den Schlüssel überhaupt nicht schrieb. Entfernen Sie das gesamte DNS-Wörterbuch oder nur den störenden Schlüssel, speichern Sie erneut und versuchen Sie es dann auf derselben Maschine, bevor Sie irgendetwas anderes ändern. Diese eine Änderung ist meist die ganze Reparatur.

Das Werkzeug hat eine Falle, die man kennen sollte, bevor man ihm vertraut. Nachdem der Schlüssel gelöscht war, setzte das Speichern derselben Verbindung ihn nicht wieder ein, und er erschien erst wieder, als eine Verbindung von Grund auf neu erstellt wurde. Behandeln Sie jedes frisch erzeugte Profil als verdächtig und prüfen Sie es, besonders wenn ein ganzer Satz Verbindungen in einem Durchgang erstellt wurde.

Der MDM-Weg scheitert woanders

Ein Verwaltungsdienst, der dasselbe Profil verteilt, kann an einer anderen Stelle scheitern: Der Client beklagt, dass überhaupt kein VPN-Dienst angelegt wurde. Im gemeldeten Fall war eine Payload für Zertifikatsauthentifizierung konfiguriert und verlangte dennoch ein Kennwortfeld; das Ausfüllen mit einem Platzhalter ließ das Profil greifen, und nichts verwendete diesen Wert jemals zur Authentifizierung.

Wenn Sie diesen Weg gehen, speichern Sie eine Dummy-Zeichenfolge und niemals echte Zugangsdaten, und halten Sie das eigentliche Geheimnis aus dem Profilkörper heraus. Ein Profil mit einem funktionierenden Kennwort wird zu einer Datei, die wie ein Schlüssel geschützt werden muss, und das ist ein deutlich größeres Problem als der fehlgeschlagene Import, mit dem Sie begonnen haben. Legen Sie fest, wem dieser Platzhalter gehört, bevor das Profil verteilt wird, damit ihn später niemand für einen Wert hält, der rotiert werden sollte. Zu dokumentieren, warum er existiert, kostet eine Zeile und erspart in sechs Monaten eine Diskussion.

Prüfen Sie, ob das Profil wirklich angekommen ist

Ein erfolgreicher Import ist kein laufender Dienst, prüfen Sie deshalb in dieser Reihenfolge:

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

Der erste Befehl listet installierte Payloads auf; der zweite sagt, ob überhaupt ein VPN-Dienst existiert. Der letzte, nach dem Verbinden ausgeführt, zeigt den Resolver, den das System wirklich nutzen wird. Lesen Sie sie in dieser Reihenfolge und hören Sie dort auf, wo die Kette reißt, denn ein fehlender Dienst macht jede Frage zum Resolver sinnlos. Ein Profil kann als installiert gelistet sein und trotzdem nichts Brauchbares besitzen, und genau diesen Zustand soll diese Abfolge aufdecken.

Sollte der Tunnel hochkommen, während ein Diensteintrag noch keinen brauchbaren Namen hat, ging das Feld für den Anzeigenamen beim Export verloren, und die Heilung ist ein neu erzeugtes Profil statt einer Umbenennung auf dem Client. Wenn der Resolver weiter auf den lokalen zeigt, wurde die DNS-Payload gründlicher entfernt als beabsichtigt.

Rollen Sie stufenweise aus, einen Mac nach dem anderen

Installieren Sie auf einem verwalteten Mac mit demselben OS-Build und prüfen Sie dann drei Dinge getrennt: Der Dienst erscheint, der Resolver ändert sich, und eine echte interne Anfrage gelingt. Erst wenn alle drei zutreffen, sollte der Umfang wachsen.

Das sind drei verschiedene Ergebnisse, die auf drei verschiedene Arten scheitern, und genau das macht eine Testmaschine die zehn Minuten wert. Ein Profil, das sich importieren lässt, ist kein Profil, das funktioniert, und die Maschine der ersten Stufe fängt beide Fehlerarten ab, bevor der Rest des Bestands eine davon sieht.

Ähnliche Artikel