Az SSID-alapú tűzfal-szabály a Wi-Fi váltás után abbahagyta a szűrést

A szabály egyszerű volt: csak akkor szűrje a forgalmat, amíg a telefon az iroda Wi-Fi-jéhez csatlakozik. Hónapokig tartotta magát, aztán egy reggel a telefon ugyanazon az SSID-n ült ugyanazzal a kulcs ikonnal, és a szűrés leállt. A hálózaton semmi nem változott; az változott meg, hogy az alkalmazás látja-e a hálózat nevét. Androidon a „melyik Wi-Fi-n vagyok” és a „blokkold ezt a forgalmat” két külön feladat, és az a tűzfal, amely összekeveri őket, pontosan akkor hibázik nyitva, amikor a név elérhetetlenné válik.

A tünet: eltűnik az azonosítás, és követi a házirend

Az SSID-szabály beolvas egy értéket, majd ágat választ. Amikor az olvasás semmi hasznosat nem ad vissza, a kódnak tennie kell valamit, és a szokásos alapértelmezés: „nem a várt hálózat, tehát ne szűrj”. Ez az alapértelmezés engedélyproblémából forgalomszivárgást csinál. A kulcs ikon látható marad, mert a VPN-szolgáltatás még fut; csak egy másik ágat érvényesít.

Nézze az események sorrendjét, ne a hálózatot. Egy elutasított engedélykérés, egy rendszerfrissítés, amely más engedély mögé tette az SSID-hozzáférést, kikapcsolt helymeghatározás vagy a munkaprofil házirendjének változása mind ugyanazt az eredményt adhatja, miközben a telefon ugyanazon a hozzáférési ponton marad.

Miért jöhet vissza ismeretlenként a név

A WifiInfo.getSSID() az aktuális hálózat szolgáltatáskészlet-azonosítóját adja vissza, és az Android dokumentálja, hogy a helyérzékeny mezőkhöz való hozzáférés engedélytől függ. Amikor a hozzáférés nem elérhető, a hívás UNKNOWN_SSID-t ad vissza a hangos hiba helyett. Az üres vagy ismeretlen érték tehát nem bizonyítja, hogy a telefon elhagyta a Wi-Fi-t; azt bizonyítja, hogy az alkalmazás nem tudja osztályozni a hálózatot.

Két ellenőrzés választja szét az eseteket. Erősítse meg, hogy a telefon csatlakozik, és nézze meg, mit jelent a rendszer, majd erősítse meg, hogy az alkalmazás valóban birtokolja-e az ezen az Android-kiadáson szükséges engedélyt:

adb shell cmd wifi status
adb shell dumpsys package <your.app> | grep -i -E "ACCESS_FINE_LOCATION|NEARBY_WIFI_DEVICES"

Ha az állapotsor csatlakozott hálózatot mutat, miközben az alkalmazás ismeretlen nevet lát, engedély- vagy API-szintű problémája van, nem Wi-Fi-probléma. Javítsa ki, mielőtt a tűzfalszabályokhoz nyúlna, mert minden további szabály olyan értékhez mérve értékelődik, amelyet az alkalmazás nem tud beolvasni.

Hol fut valójában a szűrés

A helyi Android-tűzfal általában a VpnService modelljét használja anélkül, hogy távoli kiszolgálóra küldené a forgalmat: átveszi a virtuális interfészt, saját szabályait alkalmazza, és továbbítja azt, amit engedélyez. A platform felhasználói profilonként egy aktív VPN-szolgáltatást enged, és a második lecseréli az elsőt, nem pedig rátelepül. Egy külön tűzfalalkalmazás és egy külön munka-VPN tehát nem alkot kétszintű láncot; az egyikük nyer.

Ez az SSID-szabály szempontjából fontos, mert a kényszerítési pont és a megfigyelési pont különböző összetevők. A VpnService dönti el, mi hagyja el az eszközt; a Wi-Fi API csak címkét ad. Az alkalmazás helyesen kényszeríthet és hibásan osztályozhat, és pontosan ez a hiba ebben a cikkben.

Adjon az ismeretlennek saját házirendet

Tekintse a hálózati azonosítást három állapotnak, és írja le mindegyik házirendjét, mielőtt kiadja a szabályt. A harmadik állapot az, amelyről megfeledkeznek, és ebbe helyezi önt egy támadó vagy egy hibás konfiguráció.

Zárt hibázás azt jelenti, hogy az ismeretlen állapot a legszigorúbb ésszerű házirendet örökli a legkényelmesebb helyett. Ha ettől a telefon használhatatlanná válik egy új hálózaton, a helyes megoldás egy szándékos, látható kivétel, nem pedig egy üres érték vizsgálatába rejtett csendes bizalmi döntés.

Egy ismerős SSID címke, nem bizonyíték a hálózat üzemeltetőjére. Bárki futtathat hozzáférési pontot az iroda nevével, ezért a névegyezés soha nem lehet az egyetlen dolog egy érzékeny munkamenet és egy nem megbízható szegmens között.

Az átmeneteket tesztelje, ne az állandósult állapotot

Az állandósult állapot tesztjei azon a hálózaton mennek át, ahol a szabályt építette. A hibák az átmenetekben élnek: megtagadott engedély, Wi-Fi-ről mobilra, egyik SSID-ról a másikra, újraindított VPN-szolgáltatás és egy másik VPN-alkalmazás, amely átveszi az interfészt. Mindegyiknél döntse el, hogy a meglévő kapcsolatok újraértékelődnek-e, és hogy a védett forgalom blokkolva marad-e, amíg az állapot ismeretlen.

Írja le az eredményt három mondatban: a megfigyelt feltétel, a döntést kényszerítő összetevő és a szándékos tartalék viselkedés. Ha bármelyik hiányzik a háromból, a szabály még nem házirend; ez egy találgatás, amely véletlenül működik az irodai hálózaton.