Чому ваш застосунок для iPhone не може ввімкнути або вимкнути системний VPN

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

Почніть із трьох речей, які має на увазі користувач

Розділіть смисли, перш ніж розділяти API. Іноді користувач хоче, щоб тунель вашого застосунку був підключений, іноді — щоб перемикач у Налаштуваннях увімкнувся для профілю, встановленого кимось іншим, а іноді — щоб телефон не міг вийти в мережу без тунелю. Це відповідає трьом різним механізмам, і лише перший відкритий звичайному застосунку.

Другий смисл і породжує питання на Stack Overflow, і підтримуваної відповіді на нього немає. Перемикач у Налаштуваннях належить користувачеві, а на керованих пристроях — профілю. Жоден публічний API не перелічує конфігурації VPN, не повідомляє, чи піднято системний тунель, і не перемикає його.

Що застосунок справді може створити

NetworkExtension дає застосунку власну конфігурацію через NEVPNManager. З правом Personal VPN і згодою користувача застосунок зберігає конфігурацію, яка з’являється в Налаштуваннях під його іменем, і може запустити або зупинити саме це з’єднання. Це реальна, придатна до перевірки можливість, і це ж увесь обсяг: менеджер читає й записує лише те, що створив сам.

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

Згода діє і в момент збереження. Запис конфігурації питає користувача, і це питання не те, що застосунок може придушити заради зручності.

Читання стану впирається в ту саму стіну

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

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

On Demand і Always On — справжні важелі

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

Always On VPN — це механізм примусу, і він прив’язаний до нагляду. На пристрої під наглядом MDM встановлює профіль, який тримає тунель піднятим; на особистому телефоні без нагляду ті самі ключі не дають тієї самої поведінки. Ця асиметрія навмисна, і жодна комбінація ключів корисного навантаження її не прибирає. Коли вимога справді в тому, що VPN має бути ввімкнений, вимога насправді в тому, що пристроєм треба керувати.

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

Постачайте підтримуваний шлях

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

Приватний API, який шарудить у системному VPN, пройде демонстрацію і провалить перевірку, а якщо його постачити іншим шляхом, він зламається в наступному релізі iOS. Немає версії цього обміну, яка була б варта одного перемикача.

Телеметрія керування — окремий канал: вона повідомляє, що профіль встановлено і чи відповідає пристрій, а це звітність, а не поверхня керування для кожного застосунку. Тестуйте потік на реальному пристрої після кожного оновлення, бо підтримувана поведінка живе в ОС, а ОС рухається.