Правило заштитног зида по SSID-у престало је да филтрира после промене Wi-Fi мреже
Заштитни зид везан за SSID отвара се када Android врати непознато име мреже. Одвојте идентитет од спровођења и дајте непознатом стању сопствену политику.
Правило је било једноставно: филтрирај саобраћај само док је телефон повезан на канцеларијски Wi-Fi. Држало се месецима, а онда је једног јутра телефон стајао на истом SSID-у са истом иконом кључа, а филтрирање је престало. На мрежи се ништа није променило; променило се то да ли апликација види име мреже. На Android-у су „на ком сам Wi-Fi-ју“ и „блокирај овај саобраћај“ два одвојена посла, а заштитни зид који их стапа отвара се управо кад име постане недоступно.
Симптом: идентитет нестаје, политика иде за њим
Правило по SSID-у чита вредност и затим бира грану. Када читање не врати ништа корисно, код мора нешто да уради, а уобичајени задати избор је „није очекивана мрежа, дакле не филтрирај“. Тај задати избор претвара проблем дозволе у цурење саобраћаја. Икона кључа остаје видљива јер VPN сервис још ради; само спроводи другу грану.
Гледајте редослед догађаја, а не мрежу. Одбијен захтев за дозволу, ажурирање система које је преместило приступ SSID-у иза друге дозволе, искључене услуге локације или промена политике радног профила, све то може дати исти резултат док телефон остаје на истој приступној тачки.
Зашто име може доћи као непознато
WifiInfo.getSSID() враћа идентификатор скупа услуга тренутне мреже, а Android документује да приступ пољима осетљивим на локацију зависи од дозволе. Када приступ није доступан, позив враћа UNKNOWN_SSID уместо да гласно не успе. Празна или непозната вредност зато није доказ да је телефон напустио Wi-Fi; то је доказ да апликација не може да класификује мрежу.
Две провере раздвајају случајеве. Потврдите да је телефон повезан и погледајте шта систем пријављује, а затим потврдите да апликација заиста има дозволу која јој треба на овом издању Androida:
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 одлучује шта напушта уређај; Wi-Fi API само даје ознаку. Апликација може исправно спроводити и погрешно класификовати, а то је управо квар у овом чланку.
Дајте непознатом сопствену политику
Третирајте идентитет мреже као три стања и запишите политику за свако пре него што пустите правило. Треће стање је оно које се заборавља, и у њега ће вас ставити нападач или погрешна конфигурација.
| 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 апликација која преузима сучеље. За сваки одлучите хоће ли се постојеће везе преиспитати и остаје ли заштићени саобраћај блокиран док је стање непознато.
Запишите резултат у три реченице: уочени услов, компонента која спроводи одлуку и намерни резервни поступак. Ако било које од троје недостаје, правило још није политика; то је нагађање које случајно ради на канцеларијској мрежи.