SSID-brannmurregelen slutta å filtrera etter eit Wi-Fi-byte
Ein brannmur bunden til SSID feilar ope når Android returnerer eit ukjent nettverksnamn. Skil identitet frå handheving og gje det ukjende si eiga policy.
Regelen var enkel: filtrer trafikk berre medan telefonen er på kontorets Wi-Fi. Han heldt i månadsvis, og så ein morgon sat telefonen på same SSID med same nøkkelikon, og filtreringa hadde stoppa. Ingenting ved nettverket hadde endra seg; det som hadde endra seg, var om appen kunne sjå namnet på nettverket. På Android er «kva Wi-Fi er eg på» og «blokker denne trafikken» to separate jobbar, og ein brannmur som slår dei saman, feilar ope nettopp når namnet blir utilgjengeleg.
Symptomet: identiteten forsvinn, og policyen følgjer etter
Ein SSID-regel les ein verdi og vel så ei grein. Når lesinga ikkje returnerer noko nyttig, må koden gjere noko, og standardvalet er «ikkje det forventa nettverket, så ikkje filtrer». Det gjer eit løyveproblem om til ein trafikklekkasje. Nøkkelikonet blir verande synleg fordi VPN-tenesta framleis køyrer; ho handhevar berre ei anna grein.
Sjå på rekkjefølgja av hendingar, ikkje på nettverket. Ein avvist løyvedialog, ei systemoppdatering som flytta SSID-tilgang bak eit anna løyve, avslåtte posisjonstenester eller ei endra policy for arbeidsprofilen kan alle gje same resultat medan telefonen blir verande på same aksesspunkt.
Kvifor namnet kan kome tilbake som ukjent
WifiInfo.getSSID() returnerer tenestesettidentifikatoren for det gjeldande nettverket, og Android dokumenterer at tilgang til posisjonssensitive felt er avhengig av løyve. Når tilgangen ikkje er tilgjengeleg, returnerer kallet UNKNOWN_SSID i staden for å feile høgt. Ein tom eller ukjend verdi er derfor ikkje prov på at telefonen har forlate Wi-Fi; det er prov på at appen ikkje kan klassifisere nettverket.
To kontrollar skil tilfella. Stadfest at telefonen er tilkopla og sjå kva systemet rapporterer, og stadfest deretter at appen faktisk har løyvet han treng på denne Android-utgåva:
adb shell cmd wifi status
adb shell dumpsys package <your.app> | grep -i -E "ACCESS_FINE_LOCATION|NEARBY_WIFI_DEVICES"Viss statuslinja viser eit tilkopla nettverk medan appen ser eit ukjent namn, har du eit løyve- eller API-nivåproblem, ikkje eit Wi-Fi-problem. Rett det før du rører brannmurreglane, fordi kvar regel lenger nede blir vurdert mot ein verdi appen ikkje kan lese.
Kvar filtreringa faktisk køyrer
Ein lokal Android-brannmur brukar vanlegvis VpnService-modellen utan å sende trafikk til ein ekstern server: han tek det virtuelle grensesnittet, brukar eigne reglar og videresender det han tillét. Plattforma tillét éin aktiv VPN-teneste per brukarprofil, og ein andre erstattar den første i staden for å stable seg oppå han. Ein separat brannmur-app og ein separat jobb-VPN utgjer derfor ikkje ei kjede i to trinn; ein av dei vinn.
Det betyr noko for ein SSID-regel fordi handhevingspunktet og observasjonspunktet er ulike komponentar. VpnService avgjer kva som forlèt eininga; Wi-Fi-API-et leverer berre ei etikett. Ein app kan handheve rett og klassifisere feil, og det er nettopp feilen i denne artikkelen.
Gje det ukjende si eiga policy
Behandle nettverksidentiteten som tre tilstandar, og skriv policyen for kvar av dei før du slepp regelen. Den tredje tilstanden er den som blir gløymd, og det er den ein åtakar eller ein 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 lukka betyr at den ukjende tilstanden arvar den strengaste rimelege policyen i staden for den mest bekveme. Viss det gjer telefonen ubrukeleg på eit nytt nettverk, er den rette løysinga eit medvite, synleg unntak, ikkje ei stille tillitsavgjerd gøymd i ein kontroll på tom verdi.
Eit kjent SSID er ei etikett, ikkje prov for nettverksoperatøren. Kven som helst kan køyre eit aksesspunkt med namnet til kontoret, så eit namnematch bør aldri vere det einaste som står mellom ein følsam økt og eit ikkje-klarert segment.
Test overgangane, ikkje den stabile tilstanden
Testing i stabil tilstand går gjennom på nettverket der du bygde regelen. Feila lever i overgangane: avvist løyve, Wi-Fi til mobil, eitt SSID til eit anna, VPN-tenesta starta på nytt og ein annan VPN-app som tek over grensesnittet. For kvar av dei må du avgjere om eksisterande tilkoplingar blir vurderte på nytt, og om verna trafikk blir verande blokkert medan tilstanden er ukjend.
Skriv resultatet som tre setningar: den observerte føresetnaden, komponenten som handhevar avgjerda, og den medvitne fallbacken. Viss ein av dei tre manglar, er regelen enno ikkje ein policy; han er ei gissing som tilfeldigvis verkar på kontornettverket.