SSID-brannmurregelen sluttet å filtrere etter et Wi-Fi-bytte
En brannmur bundet til SSID feiler åpent når Android returnerer et ukjent nettverksnavn. Skill identitet fra håndheving og gi det ukjente sin egen policy.
Regelen var enkel: filtrer trafikk bare mens telefonen var på kontorets Wi-Fi. Den holdt i månedsvis, og så en morgen satt telefonen på samme SSID med samme nøkkelikon, og filtreringen hadde stoppet. Ingenting ved nettverket hadde endret seg; det som hadde endret seg, var om appen kunne se nettverkets navn. På Android er «hvilket Wi-Fi er jeg på» og «blokker denne trafikken» to separate jobber, og en brannmur som slår dem sammen, feiler åpent nettopp 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 returnerer noe nyttig, må koden gjøre noe, og standardvalget er «ikke det forventede nettverket, så ikke filtrer». Det gjør et tillatelsesproblem om til en trafikklekkasje. Nøkkelikonet blir værende 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 tillatelsesdialog, 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 værende på samme aksesspunkt.
Hvorfor navnet kan komme tilbake som ukjent
WifiInfo.getSSID() returnerer tjenestesettidentifikatoren for det gjeldende nettverket, og Android dokumenterer at tilgang til posisjonsfølsomme felt avhenger av tillatelse. Når tilgangen ikke er tilgjengelig, returnerer kallet UNKNOWN_SSID 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 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 det før du rø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 vanligvis VpnService-modellen uten å sende trafikk til en ekstern server: den tar det virtuelle grensesnittet, bruker 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 å stable seg oppå den. En separat brannmurapp og en separat jobb-VPN utgjør derfor ikke en kjede i to trinn; en av dem vinner.
Det betyr noe for en SSID-regel fordi håndhevingspunktet 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 feil, 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 tar over 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 en av de tre mangler, er regelen ennå ikke en policy; den er en gjetning som tilfeldigvis virker på kontorets nettverk.