VPN-profilen importeras inte i macOS: läs payloaden först

När en profil installeras rent på en Mac och avvisas på en annan har nätverket ännu inte nåtts, så certifikat, gateways och lösenord förtjänar ingen skuld. Installationsprogrammet stannade vid en payload som det inte ville acceptera, och det registrerar vanligtvis vilken. Det lämnar profilfilen och allt som genererade den som de enda förnuftiga arbetsplatserna, och gör radering av inställningar på klienten till ett sätt att förstöra bevis i stället för en reparation.

Läs profilen i stället för att återställa Macen

Exportera .mobileconfig och titta på vad den faktiskt innehåller innan du rör klienten:

plutil -p profile.mobileconfig | head -60

En VPN-profil är egentligen två payloads med olika uppgifter: com.apple.vpn.managed innehåller anslutningen och com.apple.dnsSettings.managed innehåller resolverkonfigurationen. Installationen stannar vid den första payload som installationsprogrammet avvisar, och avvisandet hamnar i systemloggen med den payloaden namngiven, så loggen är det som talar om vilket avsnitt du ska öppna. Spara en kopia av den senaste profilen som faktiskt importerades, eftersom den filen är basen som din skillnad mäts mot.

Vad generatorn i tysthet lade till

Apple Configurator 2.15, build 7A23, skickade ut följande block inuti sin DNS-payload:

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

På macOS 12.1 avvisades profiler skrivna av den builden vid import. En anslutning skapad med Configurator 2.11.1 gick in utan klagomål, eftersom den utgåvan aldrig skrev nyckeln. Ta bort hela DNS-ordboken eller bara den problematiska nyckeln, spara igen och försök sedan igen på samma maskin innan du ändrar något annat. Oftast är den enda ändringen hela reparationen.

Verktyget har en fälla som är värd att känna till innan du litar på det. Efter att nyckeln hade tagits bort satte en sparning av samma anslutning inte tillbaka den, och den dök bara upp igen när en anslutning skapades från grunden. Behandla varje nygenererad profil som misstänkt och granska den, särskilt när en hel hög anslutningar skapades i en enda sittning.

MDM-vägen misslyckas någon annanstans

En hanteringstjänst som skjuter ut samma profil kan misslyckas på ett annat ställe: klienten klagar över att ingen VPN-tjänst alls skapades. I det rapporterade fallet krävde en payload konfigurerad för certifikatautentisering ändå ett lösenordsfält; att fylla i det med en platshållare gjorde att profilen kunde tillämpas, och ingenting använde någonsin det värdet för att autentisera.

Om du tar den vägen, lagra en dummy-sträng och aldrig en riktig inloggningsuppgift, och håll den verkliga hemligheten utanför profilens kropp. En profil med ett fungerande lösenord blir en fil som måste skyddas som en nyckel, och det är ett betydligt större problem än den misslyckade importen du började med. Bestäm vem som äger den platshållaren innan profilen distribueras, så att ingen senare förväxlar den med ett värde som är värt att rotera. Att dokumentera varför den finns tar en rad och sparar en diskussion om sex månader.

Bekräfta att profilen faktiskt landade

En lyckad import är inte en fungerande tjänst, så kontrollera i den här ordningen:

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

Det första kommandot listar installerade payloads; det andra säger om det finns någon VPN-tjänst alls. Det sista, kört efter anslutning, visar den resolver som systemet verkligen kommer att använda. Läs dem i den ordningen och stanna där kedjan brister, eftersom en saknad tjänst gör varje fråga om resolvern meningslös. En profil kan vara listad som installerad och ändå inte äga något användbart, och det är precis det tillståndet den här sekvensen är gjord för att avslöja.

Om tunneln kommer upp medan en tjänstepost fortfarande saknar ett användbart namn, gick fältet för visningsnamn förlorat i exporten, och boten är en regenererad profil i stället för ett namnbyte på klienten. Om resolvern fortsätter att peka på den lokala, har DNS-payloaden tagits bort grundligare än du tänkt.

Rulla ut i etapper, en Mac i taget

Installera på en hanterad Mac med samma OS-build, kontrollera sedan tre saker var för sig: tjänsten dyker upp, resolvern ändras och en enda verklig intern begäran lyckas. Först när alla tre stämmer bör omfattningen utökas.

Det är tre olika resultat som misslyckas på tre olika sätt, och det är vad som gör en testmaskin värd de tio minuterna. En profil som importeras är inte en profil som fungerar, och maskinen i första etappen fångar båda typerna av fel innan resten av flottan ser något av dem.