Правило фаервола по 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-приложение, забирающее интерфейс. Для каждого решите, пересматриваются ли существующие соединения и остаётся ли защищённый трафик заблокированным, пока состояние неизвестно.
Запишите результат в трёх предложениях: наблюдаемое условие, компонент, применяющий решение, и намеренный запасной вариант. Если хотя бы одного из трёх нет, правило ещё не политика; это догадка, которая случайно работает в офисной сети.