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 — це список правил, які оцінюються по порядку. Кожне правило називає дію та умови, що його вибирають, і умови — найцікавіша частина: тип інтерфейсу, Wi-Fi SSID, суфікс домену 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: перевірте, а потім відрепетируйте відкат

Перевірка належить на справжньому шляху з нешкідливим трафіком: запитайте приватний ресурс, який не повинен бути публічним, підтвердьте, яку адресу пристрій показує назовні, і повторіть після перезавантаження, щоб побачити послідовність запуску, а не лише теплий стан.

Потім відпрацюйте видалення на тестовому пристрої, перш ніж воно знадобиться в продакшені. Видалення профілю повертає пристрій до попереднього стану, а знання, скільки це триває і що бачить користувач, — частина настанов. Посібник Apple з безпеки VPN — це джерело того, що платформа документує про ці політики, і його варто прочитати перед написанням конфігурації, яка стверджує більше, ніж платформа.

Тримайте три факти з першого кроку поруч із набором правил і результатами тестів. Коли наступна людина запитає, чому телефон підключається в одній мережі, а не в іншій, ці нотатки дадуть відповідь за хвилину замість перебудови.

Схожі статті