VPN для окремих застосунків на Android і режим інкогніто в Chrome: що охоплює правило

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

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

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

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

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

adb shell pm list packages | grep -i chrome

Друга перевірка: перевірте, чи може тригер колись спрацювати достатньо рано

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

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

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

Третя перевірка: перевірте дозвіл, який збираєтеся надати

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

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

Четверта перевірка: коли вимога — примусове застосування, використовуйте постійне підключення й блокування

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

adb shell settings get global always_on_vpn_app
adb shell settings get global always_on_vpn_lockdown

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

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

П'ята перевірка: опишіть робочий процес і перевірте шлях відмови

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

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