Pravilo požarnega zidu po SSID je po menjavi Wi-Fi prenehalo filtrirati
Požarni zid, vezan na SSID, odpove odprto, ko Android vrne neznano ime omrežja. Ločite identiteto od izvajanja in neznanemu stanju dajte lastno politiko.
Pravilo je bilo preprosto: filtriraj promet le, dokler je telefon povezan z Wi-Fi pisarne. Zdržalo je mesece, nato pa je nekega jutra telefon sedel na istem SSID z isto ikono ključa in filtriranje se je ustavilo. V omrežju se ni spremenilo nič; spremenilo se je, ali aplikacija vidi ime omrežja. V Androidu sta „na katerem Wi-Fi sem“ in „blokiraj ta promet“ dve ločeni opravili, požarni zid, ki ju zameša, pa odpove odprto prav takrat, ko ime ni več na voljo.
Simptom: identiteta izgine in politika ji sledi
Pravilo po SSID prebere vrednost in nato izbere vejo. Ko branje ne vrne nič uporabnega, mora koda nekaj narediti, običajna privzeta možnost pa je „ni pričakovano omrežje, torej ne filtriraj“. Ta privzeta možnost spremeni težavo z dovoljenjem v uhajanje prometa. Ikona ključa ostane vidna, ker storitev VPN še deluje; le izvaja drugo vejo.
Opazujte zaporedje dogodkov, ne omrežja. Zavrnjeno okno za dovoljenje, posodobitev sistema, ki je dostop do SSID premaknila za drugo dovoljenje, izklopljene storitve lokacije ali sprememba politike delovnega profila lahko dajo enak rezultat, medtem ko telefon ostane na isti dostopni točki.
Zakaj se ime lahko vrne kot neznano
WifiInfo.getSSID() vrne identifikator nabora storitev trenutnega omrežja, Android pa dokumentira, da je dostop do polj, občutljivih na lokacijo, odvisen od dovoljenja. Ko dostopa ni, klic vrne UNKNOWN_SSID namesto glasne napake. Prazna ali neznana vrednost torej ni dokaz, da je telefon zapustil Wi-Fi; je dokaz, da aplikacija omrežja ne more razvrstiti.
Dva pregleda ločita primera. Potrdite, da je telefon povezan, in poglejte, kaj poroča sistem, nato potrdite, da ima aplikacija res dovoljenje, ki ga v tej različici Androida potrebuje:
adb shell cmd wifi status
adb shell dumpsys package <your.app> | grep -i -E "ACCESS_FINE_LOCATION|NEARBY_WIFI_DEVICES"Če vrstica stanja kaže povezano omrežje, aplikacija pa vidi neznano ime, imate težavo z dovoljenjem ali na ravni API, ne težave z Wi-Fi. Popravite to, preden se dotaknete pravil požarnega zidu, ker se vsako nadaljnje pravilo ocenjuje glede na vrednost, ki je aplikacija ne more prebrati.
Kje filtriranje dejansko teče
Krajevni Android požarni zid običajno uporablja model VpnService brez pošiljanja prometa na oddaljeni strežnik: vzame navidezni vmesnik, uporabi lastna pravila in posreduje, kar dovoli. Platforma dovoli eno dejavno storitev VPN na uporabniški profil, druga pa prvo zamenja, namesto da bi se nalagala nanjo. Ločena aplikacija požarnega zidu in ločen službeni VPN torej ne tvorita dvostopenjske verige; ena od njiju zmaga.
To je za pravilo po SSID pomembno, ker sta točka izvajanja in točka opazovanja različni komponenti. VpnService odloči, kaj zapusti napravo; API Wi-Fi le dobavi oznako. Aplikacija lahko izvaja pravilno in razvršča napačno, in prav to je okvara v tem članku.
Neznanemu dajte lastno politiko
Obravnavajte identiteto omrežja kot tri stanja in zapišite politiko za vsako, preden izdate pravilo. Tretje stanje je tisto, ki se pozabi, in vanj vas bo postavil napadalec ali napačna konfiguracija.
| 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 |
Odpovedati zaprto pomeni, da neznano stanje podeduje najstrožjo smiselno politiko, ne najpriročnejše. Če zaradi tega telefon v novem omrežju postane neuporaben, je prava rešitev namerna in vidna izjema, ne tiha odločitev o zaupanju, skrita v preverjanju prazne vrednosti.
Znana SSID je oznaka, ne dokaz upravljavca omrežja. Vsak lahko zažene dostopno točko z imenom pisarne, zato ujemanje imena ne bi smelo biti nikoli edina stvar med občutljivo sejo in nezaupanja vrednim odsekom.
Preizkusite prehode, ne stabilnega stanja
Preizkus v stabilnem stanju uspe v omrežju, kjer ste pravilo zgradili. Okvare živijo v prehodih: zavrnjeno dovoljenje, Wi-Fi v mobilno omrežje, en SSID v drugega, znova zagnana storitev VPN in druga aplikacija VPN, ki prevzame vmesnik. Za vsakega odločite, ali se obstoječe povezave ponovno pretehtajo in ali zaščiten promet ostane blokiran, dokler je stanje neznano.
Rezultat zapišite v treh stavkih: opaženi pogoj, komponenta, ki izvaja odločitev, in namerni nadomestni potek. Če manjka katera od treh, pravilo še ni politika; to je ugibanje, ki v pisarniškem omrežju slučajno deluje.