SSID-brandväggsregeln slutade filtrera efter ett Wi-Fi-byte
En brandvägg knuten till SSID fallerar öppet när Android returnerar ett okänt nätverksnamn. Skilj identitet från verkställighet och ge det okända en egen policy.
Regeln var enkel: filtrera trafik bara medan telefonen var ansluten till kontorets Wi-Fi. Den höll i månader, och sedan en morgon satt telefonen på samma SSID med samma nyckelikon och filtreringen hade upphört. Inget hos nätverket hade förändrats; det som förändrats var om appen kunde se nätverkets namn. På Android är ”vilket Wi-Fi är jag på” och ”blockera den här trafiken” två separata uppgifter, och en brandvägg som blandar ihop dem fallerar öppet just när namnet blir otillgängligt.
Symtomet: identiteten försvinner och policyn följer efter
En SSID-regel läser ett värde och väljer sedan en gren. När läsningen inte ger något användbart måste koden göra något, och standardvalet är ofta ”inte det förväntade nätverket, alltså inte filtrera”. Det gör ett behörighetsproblem till ett trafikläckage. Nyckelikonen syns fortfarande eftersom VPN-tjänsten körs; den verkställer bara en annan gren.
Titta på händelseordningen, inte på nätverket. En avvisad behörighetsdialog, en systemuppdatering som flyttade SSID-åtkomst bakom en annan behörighet, avstängda platstjänster eller en ändrad policy för arbetsprofilen kan alla ge samma resultat medan telefonen stannar på samma åtkomstpunkt.
Varför namnet kan komma tillbaka som okänt
WifiInfo.getSSID() returnerar tjänstuppsättningsidentifieraren för det aktuella nätverket, och Android dokumenterar att åtkomst till platskänsliga fält beror på behörighet. När åtkomsten inte är tillgänglig returnerar anropet UNKNOWN_SSID i stället för att misslyckas högljutt. Ett tomt eller okänt värde är därför inte bevis för att telefonen lämnat Wi-Fi; det är bevis för att appen inte kan klassificera nätverket.
Två kontroller skiljer fallen. Bekräfta att telefonen är ansluten och se vad systemet rapporterar, och bekräfta sedan att appen verkligen har den behörighet den behöver i den här Android-versionen:
adb shell cmd wifi status
adb shell dumpsys package <your.app> | grep -i -E "ACCESS_FINE_LOCATION|NEARBY_WIFI_DEVICES"Om statusraden visar ett anslutet nätverk medan appen ser ett okänt namn har du ett behörighets- eller API-nivåproblem, inte ett Wi-Fi-problem. Rätta till det innan du rör brandväggsreglerna, eftersom varje regel längre ned utvärderas mot ett värde appen inte kan läsa.
Var filtreringen faktiskt kör
En lokal Android-brandvägg använder vanligen VpnService-modellen utan att skicka trafik till en fjärrserver: den tar det virtuella gränssnittet, tillämpar egna regler och vidarebefordrar det den tillåter. Plattformen tillåter en aktiv VPN-tjänst per användarprofil, och en andra ersätter den första i stället för att staplas ovanpå den. En separat brandväggsapp och en separat jobb-VPN bildar därför ingen kedja i två steg; en av dem vinner.
Det spelar roll för en SSID-regel eftersom verkställighetspunkten och observationspunkten är olika komponenter. VpnService avgör vad som lämnar enheten; Wi-Fi-API:et levererar bara en etikett. En app kan verkställa korrekt och klassificera fel, och det är precis felet i den här artikeln.
Ge det okända en egen policy
Behandla nätverksidentiteten som tre tillstånd och skriv policyn för var och en innan du släpper regeln. Det tredje tillståndet är det som glöms bort, och det är dit en angripare eller en felkonfiguration placerar dig.
| 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 |
Att fallera stängt betyder att det okända tillståndet ärver den strängaste rimliga policyn i stället för den bekvämaste. Om det gör telefonen oanvändbar i ett nytt nätverk är den rätta lösningen ett medvetet, synligt undantag, inte ett tyst tillitsbeslut gömt i en kontroll av tomt värde.
Ett känt SSID är en etikett, inte bevis för nätverksoperatören. Vem som helst kan köra en åtkomstpunkt med kontorets namn, så en namnmatchning bör aldrig vara det enda som står mellan en känslig session och ett icke betrott segment.
Testa övergångarna, inte det stabila tillståndet
Test i stabilt tillstånd går igenom i nätverket där du byggde regeln. Felen lever i övergångarna: avvisad behörighet, Wi-Fi till mobil, ett SSID till ett annat, VPN-tjänsten omstartad och en annan VPN-app som tar över gränssnittet. För var och en måste du avgöra om befintliga anslutningar omprövas och om skyddad trafik förblir blockerad medan tillståndet är okänt.
Skriv resultatet som tre meningar: det observerade villkoret, komponenten som verkställer beslutet och den medvetna reservhandlingen. Om någon av de tre saknas är regeln ännu inte en policy; det är en gissning som råkar fungera i kontorets nätverk.