VPN профилот не се увезува на macOS: прво прочитајте го товарот

Профил што се одбива на еден Mac, а се прифаќа на друг, обично е проблем со товарот. Споредете го XML-от, проверете што додал генераторот, потоа проверете ја услугата.

Кога профилот се инсталира чисто на еден Mac, а на друг се одбива, мрежата сѐ уште не е достигната, па сертификатите, портите и лозинките не заслужуваат вина. Инсталаторот застана на товар што не сакаше да го прифати и обично запишува кој е. Тоа ги остава датотеката на профилот и сѐ што го создало како единствени разумни места за работа, а бришењето поставки на клиентот станува начин да се уништат докази, а не поправка.

Прочитајте го профилот наместо да го ресетирате Mac-от

Извезете го .mobileconfig и погледнете што навистина содржи пред да го допрете клиентот:

plutil -p profile.mobileconfig | head -60

VPN профилот е всушност два товара со различни задачи: com.apple.vpn.managed ја држи врската, а com.apple.dnsSettings.managed ја држи конфигурацијата на резолверот. Инсталацијата запира на првиот товар што инсталаторот го одбива, а одбивањето завршува во системскиот дневник со името на тој товар, па токму дневникот ви кажува кој дел да го отворите. Зачувајте копија од последниот профил што сепак се увезе, бидејќи таа датотека е основата со која се мери вашата разлика.

Што генераторот тивко додаде

Apple Configurator 2.15, издание 7A23, го издаде следниов блок во својот DNS товар:

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

На macOS 12.1, профилите напишани од тоа издание беа одбиени при увезувањето. Врската направена со Configurator 2.11.1 влезе без никаква забелешка, бидејќи тоа издание воопшто не го пишуваше клучот. Отстранете го целиот DNS речник или само проблематичниот клуч, зачувајте повторно, па обидете се повторно на истата машина пред да смените нешто друго. Обично таа една измена е целата поправка.

Алатката има стапица што вреди да се знае пред да ѝ се верува. Откако клучот беше избришан, зачувувањето на истата врска не го врати, и тој повторно се појави само кога врската беше создадена од нула. Третирајте го секој новосоздаден профил како сомнителен и прегледајте го, особено кога цела серија врски е направена во едно седење.

MDM патеката не успева на друго место

Услуга за управување што го турка истиот профил може да не успее на друго место: клиентот се жали дека воопшто не е создадена VPN услуга. Во пријавениот случај, товар конфигуриран за потврдување со сертификат сепак бараше поле за лозинка; неговото пополнување со замена дозволи профилот да се примени, и ништо никогаш не ја искористи таа вредност за потврдување.

Ако ја изберете таа патека, чувајте лажен текст и никогаш вистински акредитиви, а вистинската тајна држете ја надвор од телото на профилот. Профил што носи работна лозинка станува датотека што мора да се заштити како клуч, а тоа е значително поголем проблем од неуспешното увезување со кое почнавте. Одлучете кому му припаѓа таа замена пред профилот да се дистрибуира, за да не ја сфати некој подоцна како вредност што вреди да се ротира. Документирањето зошто постои зафаќа една линија и штеди расправија по шест месеци.

Потврдете дека профилот навистина слета

Успешното увезување не е работна услуга, па проверете по овој редослед:

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

Првата наредба ги наведува инсталираните товари; втората кажува дали воопшто постои VPN услуга. Последната, извршена по поврзувањето, го покажува резолверот што системот навистина ќе го користи. Читајте ги по тој редослед и застанете каде што ланецот се кине, бидејќи услуга што недостасува го прави секое прашање за резолверот бесмислено. Профилот може да биде наведен како инсталиран, а сепак да не поседува ништо употребливо, и токму таа состојба треба да ја открие оваа низа.

Ако тунелот се крене додека записот за услугата сѐ уште нема употребливо име, полето за прикажаното име е изгубено при извезувањето, а лекот е регенериран профил, а не преименување на клиентот. Ако резолверот продолжува да покажува кон локалниот, DNS товарот е отстранет потемелно отколку што сакавте.

Воведувајте во фази, по еден Mac

Инсталирајте на еден управуван Mac со истото издание на ОС, потоа проверете три работи одделно: услугата се појавува, резолверот се менува и едно вистинско внатрешно барање успева. Дури по сите три треба да се прошири опфатот.

Тоа се три различни резултати што не успеваат на три различни начини, и токму тоа ја прави една тест-машина вредна тие десет минути. Профилот што се увезува не е профил што работи, а машината од првата фаза ги фаќа двата вида отказ пред остатокот од флотата да види било кој.

Поврзани статии