Profil VPN nie importuje się w macOS: najpierw przeczytaj ładunek
Profil odrzucany na jednym Macu, a akceptowany na innym, to zwykle problem z ładunkiem. Porównaj XML, sprawdź, co dodał generator, a potem zweryfikuj usługę.
Gdy profil instaluje się bez problemu na jednym Macu, a na innym zostaje odrzucony, sieć nie została jeszcze osiągnięta, więc certyfikaty, bramy i hasła nie zasługują na winę. Instalator zatrzymał się na ładunku, którego nie chciał przyjąć, i zwykle zapisuje, na którym. Zostają więc plik profilu i wszystko, co go wygenerowało, jako jedyne rozsądne miejsce pracy, a czyszczenie ustawień na kliencie staje się sposobem niszczenia dowodów, a nie naprawą.
Przeczytaj profil zamiast resetować Maca
Wyeksportuj .mobileconfig i zobacz, co naprawdę zawiera, zanim dotkniesz klienta:
plutil -p profile.mobileconfig | head -60
Profil VPN to w rzeczywistości dwa ładunki o różnych zadaniach: com.apple.vpn.managed zawiera połączenie, a com.apple.dnsSettings.managed zawiera konfigurację resolvera. Instalacja zatrzymuje się na pierwszym ładunku, który instalator odrzuca, a odrzucenie trafia do dziennika systemowego z nazwą tego ładunku, więc to dziennik mówi, którą sekcję otworzyć. Zachowaj kopię ostatniego profilu, który się zaimportował, bo ten plik jest podstawą, względem której mierzona jest Twoja różnica.
Co generator po cichu dodał
Apple Configurator 2.15, kompilacja 7A23, wyemitował następujący blok w swoim ładunku DNS:
<key>DNS</key>
<dict>
<key>SupplementalMatchDomainsNoSearch</key>
<integer>0</integer>
</dict>
W macOS 12.1 profile zapisane przez tę kompilację były odrzucane przy imporcie. Połączenie utworzone w Configuratorze 2.11.1 weszło bez skargi, bo to wydanie w ogóle nie zapisywało klucza. Usuń cały słownik DNS albo tylko problematyczny klucz, zapisz ponownie, a potem spróbuj jeszcze raz na tej samej maszynie, zanim zmienisz cokolwiek innego. Zwykle ta jedna zmiana to cała naprawa.
Narzędzie ma pułapkę, którą warto znać, zanim mu zaufasz. Po usunięciu klucza zapisanie tego samego połączenia nie przywróciło go, a pojawił się on ponownie dopiero wtedy, gdy połączenie utworzono od zera. Każdy świeżo wygenerowany profil traktuj jako podejrzany i obejrzyj go, zwłaszcza gdy całą partię połączeń zrobiono za jednym posiedzeniem.
Ścieżka MDM zawodzi gdzie indziej
Usługa zarządzania, która wypycha ten sam profil, może zawieść w innym miejscu: klient skarży się, że nie utworzono żadnej usługi VPN. W zgłoszonym przypadku ładunek skonfigurowany do uwierzytelniania certyfikatem mimo to wymagał pola hasła; wypełnienie go wartością zastępczą pozwoliło zastosować profil, a nic nigdy nie użyło tej wartości do uwierzytelnienia.
Jeśli wybierzesz tę ścieżkę, przechowuj ciąg zastępczy i nigdy prawdziwe dane uwierzytelniające, a prawdziwy sekret trzymaj poza treścią profilu. Profil z działającym hasłem staje się plikiem, który trzeba chronić jak klucz, a to znacznie większy problem niż nieudany import, od którego zacząłeś. Zdecyduj, do kogo należy ta wartość zastępcza, zanim profil zostanie rozdany, żeby nikt później nie uznał jej za wartość wartą rotacji. Udokumentowanie, dlaczego istnieje, zajmuje jedną linijkę i oszczędza kłótnię za pół roku.
Potwierdź, że profil naprawdę dotarł
Udany import to nie działająca usługa, więc sprawdzaj w tej kolejności:
profiles show -type configuration
scutil --nc list
scutil --nc start "Your VPN Service"
scutil --nc status "Your VPN Service"
scutil --dns | head -20
Pierwsze polecenie wylicza zainstalowane ładunki; drugie mówi, czy w ogóle istnieje usługa VPN. Ostatnie, uruchomione po połączeniu, pokazuje resolver, którego system naprawdę użyje. Czytaj je w tej kolejności i zatrzymaj się tam, gdzie łańcuch się urywa, bo brakująca usługa czyni każde pytanie o resolver bezsensownym. Profil może być wykazany jako zainstalowany i mimo to nie mieć nic użytecznego, i dokładnie ten stan ta sekwencja ma ujawnić.
Jeśli tunel się podniesie, a wpis usługi nadal nie ma użytecznej nazwy, pole nazwy wyświetlanej przepadło przy eksporcie, a lekarstwem jest ponownie wygenerowany profil, nie zmiana nazwy na kliencie. Jeśli resolver nadal wskazuje lokalny, ładunek DNS usunięto dokładniej, niż zamierzałeś.
Wdrażaj etapami, po jednym Macu
Zainstaluj na jednym zarządzanym Macu z tą samą kompilacją systemu, a potem sprawdź trzy rzeczy osobno: usługa się pojawia, resolver się zmienia i jedno prawdziwe wewnętrzne żądanie się udaje. Dopiero po wszystkich trzech wolno rozszerzać zakres.
To trzy różne wyniki, które zawodzą na trzy różne sposoby, i właśnie dlatego jedna maszyna testowa jest warta tych dziesięciu minut. Profil, który się importuje, to nie profil, który działa, a maszyna pierwszego etapu wychwytuje oba rodzaje awarii, zanim reszta floty zobaczy którąkolwiek.