Always-on і блокування без VPN на Android: оберіть правильну пару

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

Два перемикачі з різними обіцянками

Always-on — це обіцянка постійності. Система підтримує вибрану службу VPN у роботі протягом подій життєвого циклу, які вона підтримує, і перезапускає її, коли вона падає. Блокування — це обіцянка ізоляції: поки тунель непридатний, охоплений трафік не має шляху поза ним. Сервер, який не працює, запит пароля, на який нікому відповісти, або клієнт, що впав, — усе це залишає пристрій із блокуванням навмисно офлайн.

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

Рішення перше: керований пристрій чи налаштування користувача?

На керованому пристрої контролер політики пристрою може володіти always-on і блокуванням для профілю, а локальний перемикач може бути відсутнім, неактивним або скидатися під час наступного оновлення політики. Це політика працює, а не помилка, яку треба обходити. Перевірте політику, перш ніж шукати приховане меню, і змінюйте вимогу в політиці, а не на кінцевій точці.

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

Область — за профілем, а не за пристроєм. Особистий і робочий профілі — це окремі контексти, і Android дозволяє один активний VPN на профіль користувача.

Блокування в робочому профілі нічого не говорить про особистий бік, і тестування одного контексту не перевіряє інший.

Рішення друге: блокувати все чи виключити деякі застосунки?

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

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

Рішення третє: що відбувається до розблокування і на порталі?

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

Захопні портали — це інший край. Мережа готелю або аеропорту потребує неавтентифікованого сеансу браузера, перш ніж запрацює будь-що інше, і жорстке блокування може зробити вхід неможливим. Підтримуваний варіант — затверджений робочий процес відновлення, чи то тимчасове кероване виключення, чи задокументована процедура. Це виключення має називати тригер (SSID або мережу порталу), максимальну тривалість, хто може його надати, і перевірку, що примус повертається сам собою після цього; вимкнення примусу як нез’ясований обхідний шлях — це не те виключення.

Документація платформи про клієнти VPN для Android охоплює поведінку always-on і блокування, виключення для окремих застосунків і правило одного VPN на профіль. Прочитайте її, перш ніж проєктувати навколо запам’ятованої поведінки зі старішого випуску, бо клієнт, який ви розгортаєте, може вже відрізнятися.

Перевірте офлайн-стан, а потім запишіть критерій приймання

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

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

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

• Always-on і блокування налаштовані обидва там, де платформа їх підтримує, і власник кожного налаштування відомий.
• Область застосунків обрана свідомо, і ви підтвердили, що відбувається з виключеними застосунками в режимі блокування.
• Прогалину до розблокування і робочий процес захопного порталу вирішено, а не виявлено.
• Тест збою виконано на тому класі пристроїв, який ви фактично розгортаєте.