SSID-firewallregel stopte met filteren na een Wi-Fi-wissel

De regel was simpel: verkeer filteren zolang de telefoon met de Wi-Fi van kantoor verbonden is. Het hield maanden stand, en toen zat de telefoon op een ochtend op dezelfde SSID met hetzelfde sleutelicoon en was het filteren gestopt. Aan het netwerk was niets veranderd; wat veranderd was, was of de app de naam van het netwerk kon zien. Op Android zijn „op welke Wi-Fi zit ik” en „blokkeer dit verkeer” twee aparte taken, en een firewall die ze door elkaar haalt, faalt open precies wanneer de naam niet beschikbaar is.

Het symptoom: de identiteit verdwijnt en het beleid volgt

Een SSID-regel leest een waarde en kiest dan een tak. Als het lezen niets bruikbaars oplevert, moet de code iets doen, en de gebruikelijke standaard is „niet het verwachte netwerk, dus niet filteren”. Die standaard maakt van een rechtenprobleem een verkeerslek. Het sleutelicoon blijft zichtbaar omdat de VPN-dienst nog draait; hij handhaaft alleen een andere tak.

Kijk naar de volgorde van gebeurtenissen, niet naar het netwerk. Een geweigerde rechtenvraag, een systeemupdate die SSID-toegang achter een andere rechten zette, uitgeschakelde locatiediensten of een gewijzigd beleid van het werkprofiel kunnen allemaal hetzelfde resultaat geven terwijl de telefoon op hetzelfde toegangspunt blijft.

Waarom de naam onbekend kan terugkomen

WifiInfo.getSSID() geeft de serviceset-identificatie van het huidige netwerk terug, en Android documenteert dat toegang tot locatiegevoelige velden van een recht afhangt. Als de toegang ontbreekt, geeft de aanroep UNKNOWN_SSID terug in plaats van luid te falen. Een lege of onbekende waarde is dus geen bewijs dat de telefoon de Wi-Fi heeft verlaten; het is bewijs dat de app het netwerk niet kan classificeren.

Twee controles scheiden de gevallen. Bevestig dat de telefoon verbonden is en kijk wat het systeem meldt, en bevestig dan dat de app het recht echt heeft dat hij op deze Android-versie nodig heeft:

adb shell cmd wifi status
adb shell dumpsys package <your.app> | grep -i -E "ACCESS_FINE_LOCATION|NEARBY_WIFI_DEVICES"

Als de statusregel een verbonden netwerk toont terwijl de app een onbekende naam ziet, hebt u een rechten- of API-niveauprobleem, geen Wi-Fi-probleem. Los dat op voordat u de firewallregels aanraakt, want elke regel verderop wordt getoetst aan een waarde die de app niet kan lezen.

Waar het filteren werkelijk draait

Een lokale Android-firewall gebruikt meestal het VpnService-model zonder verkeer naar een externe server te sturen: hij neemt de virtuele interface, past zijn eigen regels toe en stuurt door wat hij toestaat. Het platform staat één actieve VPN-dienst per gebruikersprofiel toe, en een tweede vervangt de eerste in plaats van erbovenop te stapelen. Een aparte firewallapp en een aparte werk-VPN vormen dus geen keten van twee stappen; een van beide wint.

Dat maakt uit voor een SSID-regel omdat het handhavingspunt en het observatiepunt verschillende componenten zijn. De VpnService beslist wat het apparaat verlaat; de Wi-Fi-API levert alleen een label. Een app kan correct handhaven en verkeerd classificeren, en dat is precies de fout in dit artikel.

Geef het onbekende een eigen beleid

Behandel de netwerkidentiteit als drie toestanden en schrijf het beleid voor elk op voordat u de regel uitbrengt. De derde toestand is degene die vergeten wordt, en daar zet een aanvaller of een verkeerde configuratie u in.

Open falen vermijden betekent dat de onbekende toestand het strengste redelijke beleid erft in plaats van het gemakkelijkste. Als de telefoon daardoor op een nieuw netwerk onbruikbaar wordt, is de juiste oplossing een bewuste, zichtbare uitzondering, geen stille vertrouwensbeslissing die in een controle op een lege waarde verborgen zit.

Een bekend SSID is een label, geen bewijs van de netwerkbeheerder. Iedereen kan een toegangspunt met de naam van kantoor draaien, dus een naamovereenkomst mag nooit het enige zijn tussen een gevoelige sessie en een onbetrouwbaar segment.

Test de overgangen, niet de stabiele toestand

Tests in stabiele toestand slagen op het netwerk waar u de regel hebt gebouwd. De fouten leven in overgangen: geweigerde rechten, Wi-Fi naar mobiel, het ene SSID naar het andere, de VPN-dienst herstart en een andere VPN-app die de interface overneemt. Beslis voor elk daarvan of bestaande verbindingen opnieuw worden beoordeeld en of beschermd verkeer geblokkeerd blijft terwijl de toestand onbekend is.

Schrijf het resultaat in drie zinnen: de waargenomen voorwaarde, het onderdeel dat de beslissing handhaaft en de bewuste terugval. Als een van de drie ontbreekt, is de regel nog geen beleid; het is een gok die toevallig werkt op het kantoornetwerk.