Де має бути правило брандмауера Android, коли VPN увімкнено
Активним може бути лише один VpnService, тому застосунок брандмауера й застосунок VPN не вишиковуються в ланцюг. Пройдіть один робочий запит і поставте кожне правило туди, де трафік справді проходить.
У вас одне речення політики: цей застосунок може звертатися до робочого сервісу й ні до чого більше. Наступне питання схоже на вибір продукту, але це питання місця, бо кожна можлива точка застосування бачить іншу частину трафіку телефона. Шлюз бачить лише те, що входить у тунель. Фільтр на боці телефона бачить лише те, що йому дозволено спостерігати. Якщо провести один запит через обидві точки, відповідь стає очевидною.
Почніть із речення, а не з продукту
Розгорніть вимогу, перш ніж щось обирати. Це означає пакет і профіль, у якому він працює, бо застосунок у робочому профілі — інший користувач, ніж той самий застосунок в особистому профілі. Це означає призначення: host, port і protocol, а не назва сервісу. Це означає шлях DNS, що розв'язує цю назву, і те, що має статися, коли тунель недоступний.
У записаному вигляді політика для прикладу має чотири рядки: робочий застосунок може звертатися до робочого сервісу; робочий застосунок не може звертатися ні до чого іншого; інші застосунки не змінюються; без тунелю робочому застосунку відмовлено, а не дозволено прямий обхід. Кожен рядок має власника, і це не всі той самий власник.
Крок 1: що може забезпечити сам телефон
Брандмауер Android без root — це VpnService, який перехоплює трафік локально, навіть коли за ним немає віддаленого тунелю. Android дозволяє лише один активний сервіс VPN на профіль користувача, тож другий застосунок брандмауера не вишиковується за першим. Він замінює його, і інтерфейс, який фільтрував перший застосунок, зникає.
Тому встановлення брандмауера поруч із клієнтом VPN рідко дає ту комбінацію, яку люди очікують. Якщо брандмауер запускається, а VPN відключається, нічого не об'єдналося; вони просто помінялися місцями. Заміна інтерфейсу — не співпраця, а симптом — тунель, який постійно падає щоразу, коли відкривається другий застосунок.
Підтримувані схеми все ж існують: фільтрування, вбудоване в клієнт VPN, який ви вже використовуєте, керовані засоби платформи через контролер політики пристрою або робочий профіль, чи архітектура, яку документує постачальник. Усе інше — експеримент, який треба перевіряти заново після кожного оновлення застосунку.
Крок 2: що може забезпечити шлюз
Щойно трафік розшифровано на дальньому кінці, шлюз може обмежити переслані пакети схваленими адресами, сервісами або автентифікованими ідентичностями VPN. Це справжнє застосування правил для всього, що виходить через нього, і правильне місце для обмеження доступу до приватних підмереж.
Чого він не отримує — це ідентичності застосунку телефона, прив'язаної до кожного звичайного пакета IP. Кілька застосунків, що ділять одну адресу тунелю, для шлюзу є одним суб'єктом, якщо тільки архітектура не дає їм окремих адрес або окремих автентифікованих ідентичностей. Тож правило на користувача на шлюзі не є правилом на застосунок на телефоні, як би його не називала консоль керування.
Крок 3: перелічіть те, що ніколи не доходить
Застосунок, виключений з VPN, що звертається до пристрою поблизу, ніколи не потрапляє на шлюз, тож вихідний брандмауер не може відхилити пакет, якого він не отримує. Те саме стосується ненавмисного прямого маршруту під час збою і вхідної експозиції в локальній мережі доступу. Це локальні межі за визначенням.
Правильне й зворотне: локальне правило, що дозволяє з'єднання, не надає доступу через ACL приватної мережі шлюзу. Один запит може підлягати обом межам, і виконання однієї нічого не говорить про іншу.
Крок 4: призначте кожному правилу шлях
Помістіть рішення в таблицю, перш ніж щось налаштовувати, бо порожні клітинки — це місця, де схеми ламаються.
| Path | Who can enforce it | Blind spot |
|---|---|---|
| Work app to the work service, tunnel up | Gateway ACL on address and service, plus a local block on other paths | The gateway cannot see which app sent the packet |
| Work app to other destinations, tunnel up | Local app-aware filter, or the gateway if those destinations are addressed there | The local filter must be the active VpnService |
| Work app with no tunnel | Local deny, so the app cannot take a direct path | Requires the filter to survive the tunnel going away |
| Nearby LAN device | Local policy only | The gateway never sees it |
Робоча форма — дві межі з двома завданнями. Локальна межа, що враховує застосунки, керує поведінкою телефона, включно з прямим обходом, а межа шлюзу керує віддаленими ресурсами. Бік шлюзу може дозволити робочий сервіс і відхилити кожну іншу приватну підмережу, тоді як політика на боці телефона сама вирішує щодо прямого маршруту, який застосунок міг би інакше обрати.
Крок 5: тримайте транспорт живим, потім перевіряйте
Яку б локальну політику ви не обрали, вона має пропускати транспорт, що встановлює й підтримує VPN. Блокування цього транспорту залишає телефон без тунелю й без політики, що нічого не застосовує послідовно і його важко діагностувати, бо застосунок просто не має мережі.
Далі перевіряйте кожен рядок початкового речення, а не загальне враження: робочий застосунок досягає робочого сервісу, той самий застосунок відхилено в іншому призначенні, неробочий застосунок поводиться як раніше, а з зупиненим тунелем робочий застосунок не переходить на пряме з'єднання. Перевірте шлях DNS окремо, бо приватний DNS або зашифрований резолвер можуть обійти фільтр, який перевіряє лише адреси.
Якщо якийсь із цих кроків не можна виконати на телефоні, вимога стає питанням архітектури, а не налаштуванням брандмауера. Розділення політики між пристроєм, яким ви керуєте, і шлюзом, яким ви керуєте, зазвичай і є чесна відповідь, а документація про підключення VPN в Android — те місце, де можна підтвердити, що платформа дозволить і не дозволить робити одному сервісу.