Правило фаєрвола за SSID перестало фільтрувати після зміни Wi-Fi
Фаєрвол, прив'язаний до SSID, відкривається, коли Android повертає невідоме ім'я мережі. Відокремте ідентичність від застосування і дайте невідомому власну політику.
Правило було простим: фільтрувати трафік лише поки телефон підключений до Wi-Fi офісу. Воно трималося місяцями, а потім одного ранку телефон сидів на тому самому SSID з тією самою іконкою ключа, а фільтрування припинилося. У мережі нічого не змінилося; змінилося те, чи бачить застосунок ім'я мережі. В Android «на якому Wi-Fi я» і «заблокуй цей трафік» — два різні завдання, і фаєрвол, який їх змішує, відкривається саме тоді, коли ім'я стає недоступним.
Симптом: ідентичність зникає, а політика йде за нею
Правило за SSID читає значення і потім вибирає гілку. Коли читання не повертає нічого корисного, код мусить щось зробити, і типова поведінка за замовчуванням — «це не очікувана мережа, отже не фільтрувати». Це перетворює проблему дозволу на витік трафіку. Іконка ключа залишається видимою, бо служба VPN ще працює; вона просто застосовує іншу гілку.
Дивіться на порядок подій, а не на мережу. Відхилений запит дозволу, оновлення системи, яке перенесло доступ до SSID за інший дозвіл, вимкнені служби геолокації або зміна політики робочого профілю можуть дати той самий результат, поки телефон залишається на тій самій точці доступу.
Чому ім'я може повернутися невідомим
WifiInfo.getSSID() повертає ідентифікатор набору служб поточної мережі, і Android документує, що доступ до полів, чутливих до місцеположення, залежить від дозволу. Коли доступу немає, виклик повертає UNKNOWN_SSID замість гучної відмови. Тому порожнє або невідоме значення не є доказом, що телефон залишив Wi-Fi; це доказ, що застосунок не може класифікувати мережу.
Дві перевірки розділяють випадки. Переконайтеся, що телефон підключений, і подивіться, що повідомляє система, потім переконайтеся, що застосунок справді має дозвіл, потрібний йому в цій версії Android:
adb shell cmd wifi status
adb shell dumpsys package <your.app> | grep -i -E "ACCESS_FINE_LOCATION|NEARBY_WIFI_DEVICES"Якщо рядок стану показує підключену мережу, а застосунок бачить невідоме ім'я, у вас проблема з дозволом або рівнем API, а не з Wi-Fi. Виправте це, перш ніж чіпати правила фаєрвола, бо кожне наступне правило оцінюється щодо значення, яке застосунок не може прочитати.
Де фільтрування насправді працює
Локальний фаєрвол Android зазвичай використовує модель VpnService, не надсилаючи трафік на віддалений сервер: він бере віртуальний інтерфейс, застосовує власні правила і пересилає те, що дозволяє. Платформа дозволяє одну активну службу VPN на профіль користувача, і друга замінює першу, а не нашаровується на неї. Тому окремий застосунок-фаєрвол і окремий робочий VPN не утворюють двоступеневого ланцюга; один із них перемагає.
Це важливо для правила за SSID, бо точка застосування і точка спостереження — різні компоненти. VpnService вирішує, що залишає пристрій; API Wi-Fi лише надає мітку. Застосунок може застосовувати правильно і класифікувати неправильно, і саме це є збоєм у цій статті.
Дайте невідомому власну політику
Розглядайте ідентичність мережі як три стани і запишіть політику для кожного, перш ніж випускати правило. Третій стан — той, який забувають, і саме в нього вас поставить нападник або хибна конфігурація.
| Observation | Policy to specify |
|---|---|
| Expected SSID is readable | The explicit filtering policy you designed |
| A different SSID is readable | The default policy for untrusted networks |
| Unknown, changing or unreadable | Fail closed until classification is reliable |
Відмовляти закрито означає, що невідомий стан успадковує найсуворішу розумну політику, а не найзручнішу. Якщо через це телефон стає непридатним у новій мережі, правильне рішення — навмисний і видимий виняток, а не тихе рішення про довіру, сховане в перевірці на порожнє значення.
Знайомий SSID — це мітка, а не доказ оператора мережі. Будь-хто може підняти точку доступу з ім'ям офісу, тому збіг імені ніколи не повинен бути єдиним, що стоїть між чутливою сесією і недовіреним сегментом.
Перевіряйте переходи, а не стабільний стан
Тести в стабільному стані проходять у мережі, де ви будували правило. Збої живуть у переходах: відмова в дозволі, з Wi-Fi на мобільну мережу, з одного SSID на інший, перезапуск служби VPN і інший застосунок VPN, що забирає інтерфейс. Для кожного вирішіть, чи переглядаються наявні з'єднання і чи залишається заблокованим захищений трафік, поки стан невідомий.
Запишіть результат у трьох реченнях: спостережувана умова, компонент, що застосовує рішення, і навмисний запасний варіант. Якщо бракує хоча б одного з трьох, правило ще не політика; це здогад, який випадково працює в офісній мережі.