Când un profil se instalează curat pe un Mac și este refuzat pe altul, rețeaua nu a fost încă atinsă, așa că certificatele, gateway-urile și parolele nu merită nicio vină. Instalatorul s-a oprit la o încărcătură pe care nu a vrut să o accepte, și de obicei notează care. Astfel rămân fișierul profilului și tot ce l-a generat ca singurele locuri rezonabile de lucru, iar ștergerea setărilor pe client devine o modalitate de a distruge dovezi în loc de o reparație.

Citiți profilul în loc să resetați Mac-ul

Exportați .mobileconfig și uitați-vă ce conține cu adevărat înainte de a atinge clientul:

plutil -p profile.mobileconfig | head -60

Un profil VPN este de fapt două încărcături cu sarcini diferite: com.apple.vpn.managed conține conexiunea, iar com.apple.dnsSettings.managed conține configurația resolver-ului. Instalarea se oprește la prima încărcătură pe care instalatorul o respinge, iar respingerea ajunge în jurnalul sistemului cu numele acelei încărcături, deci jurnalul este cel care vă spune ce secțiune să deschideți. Păstrați o copie a ultimului profil care s-a importat, pentru că acel fișier este baza față de care se măsoară diferența dumneavoastră.

Ce a adăugat generatorul în tăcere

Apple Configurator 2.15, build 7A23, a emis următorul bloc în interiorul încărcăturii sale DNS:

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

Pe macOS 12.1, profilurile scrise de acel build au fost respinse la import. O conexiune creată cu Configurator 2.11.1 a intrat fără nicio obiecție, pentru că acea versiune nu scria deloc cheia. Eliminați întregul dicționar DNS sau doar cheia problematică, salvați din nou și apoi reîncercați pe aceeași mașină înainte de a schimba orice altceva. De obicei acea singură modificare este toată reparația.

Instrumentul are o capcană pe care merită să o știți înainte de a avea încredere în el. După ce cheia a fost ștearsă, salvarea aceleiași conexiuni nu a readus-o, și ea a reapărut doar când a fost creată o conexiune de la zero. Tratați fiecare profil proaspăt generat ca suspect și inspectați-l, mai ales când un întreg lot de conexiuni a fost creat într-o singură sesiune.

Calea MDM eșuează în altă parte

Un serviciu de administrare care împinge același profil poate eșua în alt punct: clientul se plânge că nu a fost creat niciun serviciu VPN. În cazul raportat, o încărcătură configurată pentru autentificare prin certificat cerea totuși un câmp de parolă; completarea lui cu un substituent a permis aplicarea profilului, și nimic nu a folosit vreodată acea valoare pentru autentificare.

Dacă alegeți acea cale, stocați un șir fals și niciodată o acreditare reală, și țineți secretul autentic în afara corpului profilului. Un profil care poartă o parolă funcțională devine un fișier care trebuie protejat ca o cheie, iar asta este o problemă mult mai mare decât importul eșuat cu care ați început. Decideți cui aparține acel substituent înainte de distribuirea profilului, ca nimeni să nu îl confunde mai târziu cu o valoare care merită rotită. Documentarea motivului pentru care există ia o linie și economisește o ceartă peste șase luni.

Confirmați că profilul a ajuns într-adevăr

Un import reușit nu este un serviciu funcțional, așa că verificați în această ordine:

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

Prima comandă listează încărcăturile instalate; a doua spune dacă există vreun serviciu VPN. Ultima, rulată după conectare, arată resolver-ul pe care sistemul îl va folosi cu adevărat. Citiți-le în această ordine și opriți-vă acolo unde lanțul se rupe, pentru că un serviciu lipsă face orice întrebare despre resolver lipsită de sens. Un profil poate apărea ca instalat și totuși să nu posede nimic utilizabil, și exact această stare este menită să o expună această secvență.

Dacă tunelul urcă în timp ce o intrare de serviciu încă nu are un nume utilizabil, câmpul numelui afișat s-a pierdut la export, iar remediul este un profil regenerat și nu o redenumire pe client. Dacă resolver-ul continuă să indice cel local, încărcătura DNS a fost eliminată mai temeinic decât intenționați.

Implementați în etape, un Mac pe rând

Instalați pe un Mac administrat care rulează același build de sistem, apoi verificați trei lucruri separat: serviciul apare, resolver-ul se schimbă și o cerere internă reală reușește. Numai după toate trei aria trebuie extinsă.

Acestea sunt trei rezultate diferite care eșuează în trei moduri diferite, și de aceea un singur calculator de test merită cele zece minute. Un profil care se importă nu este un profil care funcționează, iar mașina din prima etapă prinde ambele tipuri de eșec înainte ca restul flotei să vadă vreunul.

Articole similare