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