SSID-brannmurregelen sluttet å filtrere etter en Wi-Fi-endring
En brannmur knyttet til SSID feiler åpent når Android gir tilbake et ukjent nettverksnavn. Skille identitet fra håndhevelse og gi det ukjente sin egen policy.
Regelen var enkel: filtrer trafikk kun mens telefonen er koblet til kontorets Wi-Fi. Den varte i månedsvis, og så en morgen sto telefonen på samme SSID med samme nøkkelikon, og filtreringen hadde opphørt. Ingenting ved nettverket hadde forandret seg; det som hadde forandret seg, var hvorvidt appen kunne se nettverkets navn. På Android er «hvilket Wi-Fi er jeg på» og «blokker denne trafikken» to atskilte oppgaver, og en brannmur som blander dem, feiler åpent akkurat når navnet blir utilgjengelig.
Symptomet: identiteten forsvinner, og policyen følger etter
En SSID-regel leser en verdi og velger deretter en gren. Når lesingen ikke gir noe nyttig tilbake, må koden gjøre noe, og den vanlige standarden er «ikke det forventede nettverket, så ikke filtrer». Denne standarden gjør et tillatelsesproblem om til en trafikklekkasje. Nøkkelikonet blir stående synlig fordi VPN-tjenesten fortsatt kjører; den håndhever bare en annen gren.
Se på rekkefølgen av hendelser, ikke på nettverket. En avvist tillatelsesforespørsel, en systemoppdatering som flyttet SSID-tilgang bak en annen tillatelse, slåtte posisjonstjenester eller en endret policy for arbeidsprofilen kan alle gi samme resultat mens telefonen blir stående på samme aksesspunkt.
Hvorfor navnet kan komme tilbake som ukjent
WifiInfo.getSSID() gir tjenestesettidentifikatoren for det gjeldende nettverket, og Android dokumenterer at tilgang til posisjonssensitive felter avhenger av tillatelse. Når tilgangen ikke er tilgjengelig, gir kallet UNKNOWN_SSID tilbake i stedet for å feile høylytt. En tom eller ukjent verdi er derfor ikke bevis for at telefonen har forlatt Wi-Fi; det er bevis for at appen ikke kan klassifisere nettverket.
To kontroller skiller tilfellene. Bekreft at telefonen er tilkoblet og se hva systemet rapporterer, og bekreft deretter at appen faktisk har den tillatelsen den trenger på denne Android-utgivelsen:
adb shell cmd wifi status
adb shell dumpsys package <your.app> | grep -i -E "ACCESS_FINE_LOCATION|NEARBY_WIFI_DEVICES"Hvis statuslinjen viser et tilkoblet nettverk mens appen ser et ukjent navn, har du et tillatelses- eller API-nivåproblem, ikke et Wi-Fi-problem. Rett på det før du berører brannmurreglene, fordi hver regel lenger ned vurderes mot en verdi appen ikke kan lese.
Hvor filtreringen faktisk kjører
En lokal Android-brannmur bruker normalt VpnService-modellen uten å sende trafikk til en ekstern server: den tar det virtuelle grensesnittet, anvender egne regler og videresender det den tillater. Plattformen tillater én aktiv VPN-tjeneste per brukerprofil, og en andre erstatter den første i stedet for å legge seg oppå den. En separat brannmurapp og en separat jobb-VPN utgjør derfor ikke en kjede i to trinn; én av dem vinner.
Det har betydning for en SSID-regel fordi håndhevelsespunktet og observasjonspunktet er forskjellige komponenter. VpnService bestemmer hva som forlater enheten; Wi-Fi-API-et leverer bare en etikett. En app kan håndheve riktig og klassifisere galt, og det er nettopp feilen i denne artikkelen.
Gi det ukjente sin egen policy
Behandle nettverksidentiteten som tre tilstander, og skriv policyen for hver av dem før du slipper regelen. Den tredje tilstanden er den som blir glemt, og det er den en angriper eller en feilkonfigurasjon plasserer deg 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 |
Å feile lukket betyr at den ukjente tilstanden arver den strengeste fornuftige policyen i stedet for den mest bekvemme. Hvis det gjør telefonen ubrukelig på et nytt nettverk, er den riktige løsningen et bevisst, synlig unntak, ikke en stille tillitsbeslutning skjult i en sjekk på tom verdi.
Et kjent SSID er en etikett, ikke bevis for nettverksoperatøren. Hvem som helst kan kjøre et aksesspunkt med kontorets navn, så et navnematch bør aldri være det eneste som står mellom en følsom økt og et ikke-klarert segment.
Test overgangene, ikke den stabile tilstanden
Testing i stabil tilstand består på nettverket der du bygde regelen. Feilene lever i overgangene: avvist tillatelse, Wi-Fi til mobil, ett SSID til et annet, VPN-tjenesten startet på nytt og en annen VPN-app som overtar grensesnittet. For hver av dem må du avgjøre om eksisterende tilkoblinger vurderes på nytt, og om beskyttet trafikk forblir blokkert mens tilstanden er ukjent.
Skriv resultatet som tre setninger: den observerte betingelsen, komponenten som håndhever beslutningen, og den bevisste fallbacken. Hvis én av de tre mangler, er regelen ennå ikke en policy; den er en gjetning som tilfeldigvis virker på kontorets nettverk.