SSID-firewallregel holdt op med at filtrere efter et Wi-Fi-skift
En SSID-baseret firewall svigter åbent, når Android returnerer et ukendt netværksnavn. Skil identitet fra håndhævelse, og giv det ukendte sin egen politik.
Reglen var enkel: filtrer kun trafik, mens telefonen var på kontorets Wi-Fi. Den holdt i månedsvis, og så en morgen sad telefonen på samme SSID med samme nøgleikon, og filtreringen var stoppet. Intet ved netværket havde ændret sig; det, der havde ændret sig, var, om appen kunne se netværkets navn. På Android er «hvilket Wi-Fi er jeg på» og «bloker denne trafik» to separate opgaver, og en firewall, der blander dem sammen, svigter åbent præcis når navnet bliver utilgængeligt.
Symptomet: identiteten forsvinder, og politikken følger efter
En SSID-regel læser en værdi og vælger derefter en gren. Når læsningen ikke returnerer noget brugbart, må koden gøre noget, og standardvalget er ofte «ikke det forventede netværk, så filtrer ikke». Det gør et tilladelsesproblem til en trafiklækage. Nøgleikonet forbliver synligt, fordi VPN-tjenesten stadig kører; den håndhæver bare en anden gren.
Se på rækkefølgen af begivenheder i stedet for på netværket. En afvist tilladelsesdialog, en systemopdatering, der flyttede SSID-adgang bag en anden tilladelse, slukkede lokalitetstjenester eller en ændret politik for arbejdsprofilen kan alle give samme resultat, mens telefonen bliver på samme adgangspunkt.
Hvorfor navnet kan komme tilbage som ukendt
WifiInfo.getSSID() returnerer tjenestesæt-identifikatoren for det aktuelle netværk, og Android dokumenterer, at adgang til lokalitetsfølsomme felter afhænger af tilladelse. Når adgangen ikke er tilgængelig, returnerer kaldet UNKNOWN_SSID i stedet for at fejle højlydt. En tom eller ukendt værdi er derfor ikke bevis for, at telefonen har forladt Wi-Fi; det er bevis for, at appen ikke kan klassificere netværket.
To kontroller skiller tilfældene. Bekræft, at telefonen er tilknyttet, og se, hvad systemet rapporterer, og bekræft derefter, at appen faktisk har den tilladelse, den har brug for på denne Android-udgivelse:
adb shell cmd wifi status
adb shell dumpsys package <your.app> | grep -i -E "ACCESS_FINE_LOCATION|NEARBY_WIFI_DEVICES"Hvis statuslinjen viser et tilsluttet netværk, mens appen ser et ukendt navn, har du et tilladelses- eller API-niveauproblem, ikke et Wi-Fi-problem. Ret det, før du rører ved firewallreglerne, fordi hver regel længere nede vurderes mod en værdi, appen ikke kan læse.
Hvor filtreringen faktisk kører
En lokal Android-firewall bruger normalt VpnService-modellen uden at sende trafik til en fjernserver: den tager det virtuelle interface, anvender sine egne regler og videresender det, den tillader. Platformen tillader én aktiv VPN-tjeneste pr. brugerprofil, og en anden erstatter den første i stedet for at stable oven på den. En separat firewall-app og en separat arbejds-VPN udgør derfor ikke en to-trins kæde; en af dem vinder.
Det betyder noget for en SSID-regel, fordi håndhævelsespunktet og observationspunktet er forskellige komponenter. VpnService beslutter, hvad der forlader enheden; Wi-Fi-API’et leverer kun en etiket. En app kan håndhæve korrekt og klassificere forkert, og det er præcis fejlen i denne artikel.
Giv det ukendte sin egen politik
Behandl netværksidentiteten som tre tilstande, og skriv politikken for hver af dem ned, før du sender reglen. Den tredje tilstand er den, der bliver glemt, og det er den, en angriber eller en fejlkonfiguration placerer dig i.
| 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 |
At svigte lukket betyder, at den ukendte tilstand arver den strengeste fornuftige politik i stedet for den mest bekvemme. Hvis det gør telefonen ubrugelig på et nyt netværk, er den rigtige løsning en bevidst, synlig undtagelse, ikke en tavs tillidsbeslutning skjult i et tjek for tom værdi.
Et velkendt SSID er en etiket, ikke bevis for netværksoperatøren. Enhver kan køre et adgangspunkt med kontorets navn, så et navnematch bør aldrig være det eneste, der står mellem en følsom session og et utroværdigt segment.
Test overgangene, ikke steady state
Test i steady state består på det netværk, hvor du byggede reglen. Fejlene lever i overgangene: nægtet tilladelse, Wi-Fi til mobilnet, et SSID til et andet, VPN-tjenesten genstartet og en anden VPN-app, der overtager interfacet. For hver af dem skal du beslutte, om eksisterende forbindelser genvurderes, og om beskyttet trafik forbliver blokeret, mens tilstanden er ukendt.
Skriv resultatet som tre sætninger: den observerede betingelse, den komponent der håndhæver beslutningen, og den bevidste fallback. Hvis en af de tre mangler, er reglen endnu ikke en politik; det er et gæt, der tilfældigvis virker på kontorets netværk.