Always On VPN и VPN On Demand на iPhone: что разворачивать

On Demand открывает туннель при совпадении правил; управляемый Always On принудительно удерживает покрытие на наблюдаемых устройствах. Руководство по выбору и доказательству работоспособности.

Два iPhone могут оба утверждать, что используют VPN, и вести себя совершенно по-разному. On Demand открывает туннель при совпадении правила, и пользователь всё ещё может отключить его в Настройках. Управляемый Always On удерживает покрытие принудительно на наблюдаемом устройстве, в том числе в моменты, когда туннель не поднимается. Выбирайте, спрашивая, что должно быть верно, когда пользователь ничего не делает, а затем проверяйте переходы, а не устойчивое состояние. Шаги ниже идут в том порядке, в котором развёртывание действительно ломается.

Шаг 1: определите, что устройство может принудительно обеспечить

Always On — функция для наблюдаемых устройств. Если парк не под наблюдением, разговор заканчивается, не начавшись, и никакой ключ payload не делает ненаблюдаемый телефон принудительным. Подтвердите наблюдение со стороны управления и с самого устройства, а затем подтвердите, кто подписал профиль.

На телефоне: Настройки, затем Основные, затем VPN и управление устройством. Запись профиля называет владельца, а личный профиль, установленный вручную, выглядит иначе, чем доставленный службой управления. Не выводите принудительность из имени профиля или маркетинговой метки поставщика; метка не является политикой платформы.

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

Шаг 2: читайте правила on-demand, а не название функции

On Demand — это список правил, оцениваемых по порядку. Каждое правило называет действие и условия, которые его выбирают, и условия — самое интересное: тип интерфейса, SSID Wi-Fi, суффикс домена DNS или URL проверки. Набор правил, который никогда не совпадает, — это функция, которая никогда не подключается.

<key>OnDemandRules</key>
<array>
  <dict>
    <key>Action</key><string>EvaluateConnection</string>
    <key>InterfaceTypeMatch</key><string>WiFi</string>
    <key>SSIDMatch</key><array><string>Office-WiFi</string></array>
  </dict>
</array>

Прочитайте весь массив и задайте два вопроса по каждому правилу: может ли это условие когда-либо быть истинным в этом парке и что происходит, когда ни одно правило не совпадает? Корпоративные сети переименовывают точки доступа, объединяют SSID и меняют суффиксы DNS, и каждое такое изменение тихо отрывает правило от реальности.

Условие суффикса DNS чаще всего ошибочно на практике, потому что суффикс, который телефон сообщает в гостевой сети, не тот, который обслуживает корпоративный резолвер. Проверьте имя, которое устройство действительно разрешает, прежде чем доверять правилу.

Шаг 3: проверяйте переходы, а не статическое соединение

Туннель, поднятый в момент вашего взгляда, доказывает очень мало. Выполняйте каждый переход намеренно и записывайте, что делает устройство, используя один и тот же частный ресурс каждый раз, чтобы результаты были сопоставимы:

  • Подключитесь к сети, где правило должно совпасть, затем запросите частный ресурс и подтвердите, что он загружается.
  • Переключитесь на сотовую сеть с приложением в фоне, затем выведите его вперёд и повторите запрос.
  • Подключитесь к Wi-Fi с captive portal и посмотрите, доступен ли портал или принудительность блокирует его до аутентификации.
  • Отключите туннель вручную на наблюдаемом устройстве и проверьте, возвращается ли он сам и как быстро.

Выполните тот же список на ненаблюдаемом устройстве, если оно есть. Разница между двумя результатами — это реальное поведение развёртывания, и именно её никогда не показывает снимок экрана подключённого туннеля.

Шаг 4: знайте две формы отказа

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

On Demand отказывает тем, что не срабатывает. Правило не совпадает, туннель не появляется, а частный ресурс просто истекает по тайм-ауту. Это легко ошибочно диагностировать как проблему сервера, потому что клиент ведёт себя точно так, как настроен.

Captive portal стоит между ними: ему нужна связность до того, как существует туннель, поэтому политика, блокирующая всё до поднятия туннеля, требует документированного пути через портал. Решайте это в проектировании, а не в службе поддержки.

Шаг 5: проверьте, затем отработайте откат

Проверка выполняется на реальном пути с безвредным трафиком: запросите частный ресурс, который не должен быть публичным, подтвердите, какой адрес устройство показывает наружу, и повторите после перезагрузки, чтобы увидеть последовательность запуска, а не только тёплое состояние.

Затем отработайте удаление на тестовом устройстве, прежде чем оно понадобится в продакшене. Удаление профиля возвращает устройство в прежнее состояние, и знание того, сколько это занимает и что видит пользователь, — часть runbook. Руководство Apple по безопасности VPN — источник того, что платформа документирует об этих политиках, и его стоит прочитать перед написанием конфигурации, которая утверждает больше, чем платформа.

Держите три факта из первого шага рядом с набором правил и результатами тестов. Когда следующий человек спросит, почему телефон подключается в одной сети и не подключается в другой, эти заметки ответят за минуту вместо перестройки.

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