Профиль 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 с той же сборкой ОС, затем проверьте три вещи по отдельности: служба появляется, распознаватель меняется и один настоящий внутренний запрос проходит. Только после всех трёх стоит расширять охват.

Это три разных результата, которые отказывают тремя разными способами, и именно поэтому одна тестовая машина стоит тех десяти минут. Профиль, который импортируется, — не профиль, который работает, и машина первого этапа ловит оба вида отказа, прежде чем остальной парк увидит хоть один.

Похожие статьи