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