SSID-Firewall-Regel filterte nach einem Wi-Fi-Wechsel nicht mehr

Die Regel war einfach: Verkehr nur filtern, solange das Telefon mit dem Büro-Wi-Fi verbunden ist. Sie hielt monatelang, und dann saß das Telefon eines Morgens auf derselben SSID mit demselben Schlüsselsymbol, und die Filterung hatte aufgehört. Am Netzwerk hatte sich nichts geändert; geändert hatte sich, ob die App den Namen des Netzwerks sehen konnte. Unter Android sind „in welchem Wi-Fi bin ich“ und „diesen Verkehr blockieren“ zwei getrennte Aufgaben, und eine Firewall, die beides vermischt, fällt genau dann offen aus, wenn der Name nicht mehr verfügbar ist.

Das Symptom: Die Identität verschwindet, die Richtlinie folgt

Eine SSID-Regel liest einen Wert und wählt dann einen Zweig. Wenn die Abfrage nichts Brauchbares zurückgibt, muss der Code etwas tun, und die übliche Voreinstellung lautet „nicht das erwartete Netzwerk, also nicht filtern“. Diese Voreinstellung macht aus einem Berechtigungsproblem ein Verkehrsleck. Das Schlüsselsymbol bleibt sichtbar, weil der VPN-Dienst noch läuft; er setzt nur einen anderen Zweig durch.

Betrachten Sie die Reihenfolge der Ereignisse statt das Netzwerk. Eine abgelehnte Berechtigungsabfrage, ein Systemupdate, das den SSID-Zugriff hinter eine andere Berechtigung verschoben hat, deaktivierte Standortdienste oder eine geänderte Richtlinie des Arbeitsprofils können alle dasselbe Ergebnis liefern, während das Telefon am selben Zugangspunkt bleibt.

Warum der Name unbekannt zurückkommen kann

WifiInfo.getSSID() gibt die Dienstsatz-Kennung des aktuellen Netzwerks zurück, und Android dokumentiert, dass der Zugriff auf standortempfindliche Felder von einer Berechtigung abhängt. Ist der Zugriff nicht verfügbar, gibt der Aufruf UNKNOWN_SSID zurück, statt laut zu scheitern. Ein leerer oder unbekannter Wert ist daher kein Beleg dafür, dass das Telefon das Wi-Fi verlassen hat; er belegt, dass die App das Netzwerk nicht einordnen kann.

Zwei Prüfungen trennen die Fälle. Bestätigen Sie, dass das Telefon verbunden ist, und sehen Sie, was das System meldet; bestätigen Sie dann, dass die App die Berechtigung tatsächlich besitzt, die sie in dieser Android-Version braucht:

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

Wenn die Statuszeile ein verbundenes Netzwerk zeigt, während die App einen unbekannten Namen sieht, haben Sie ein Berechtigungs- oder API-Ebenen-Problem, kein Wi-Fi-Problem. Beheben Sie das, bevor Sie die Firewall-Regeln anfassen, denn jede nachgelagerte Regel wird gegen einen Wert geprüft, den die App nicht lesen kann.

Wo die Filterung tatsächlich läuft

Eine lokale Android-Firewall nutzt normalerweise das VpnService-Modell, ohne Verkehr an einen entfernten Server zu senden: Sie übernimmt die virtuelle Schnittstelle, wendet eigene Regeln an und leitet weiter, was sie zulässt. Die Plattform erlaubt einen aktiven VPN-Dienst pro Benutzerprofil, und ein zweiter ersetzt den ersten, statt sich darauf zu stapeln. Eine separate Firewall-App und ein separates Arbeits-VPN bilden daher keine zweistufige Kette; eines von beiden gewinnt.

Das ist für eine SSID-Regel wichtig, weil Durchsetzungs- und Beobachtungspunkt verschiedene Komponenten sind. Der VpnService entscheidet, was das Gerät verlässt; die Wi-Fi-API liefert nur ein Etikett. Eine App kann korrekt durchsetzen und falsch einordnen, und genau das ist der Fehler in diesem Artikel.

Geben Sie dem Unbekannten eine eigene Richtlinie

Behandeln Sie die Netzwerkidentität als drei Zustände und schreiben Sie die Richtlinie für jeden auf, bevor Sie die Regel ausliefern. Der dritte Zustand ist der vergessene, und genau in ihn bringt Sie ein Angreifer oder eine Fehlkonfiguration.

Ein offener Ausfall vermeiden heißt, dass der unbekannte Zustand die strengste vernünftige Richtlinie erbt statt die bequemste. Wird das Telefon dadurch in einem neuen Netzwerk unbrauchbar, ist die richtige Lösung eine bewusste, sichtbare Ausnahme und keine stille Vertrauensentscheidung, die in einer Prüfung auf einen leeren Wert versteckt ist.

Eine vertraute SSID ist ein Etikett, kein Beweis für den Netzwerkbetreiber. Jeder kann einen Zugangspunkt mit dem Namen des Büros betreiben, daher sollte eine Namensübereinstimmung nie das Einzige sein, was zwischen einer sensiblen Sitzung und einem nicht vertrauenswürdigen Segment steht.

Testen Sie die Übergänge, nicht den Ruhezustand

Tests im Ruhezustand bestehen in dem Netzwerk, in dem Sie die Regel gebaut haben. Die Fehler leben in den Übergängen: verweigerte Berechtigung, Wi-Fi zu Mobilfunk, eine SSID zu einer anderen, neu gestarteter VPN-Dienst und eine andere VPN-App, die die Schnittstelle übernimmt. Entscheiden Sie für jeden, ob bestehende Verbindungen neu bewertet werden und ob geschützter Verkehr blockiert bleibt, solange der Zustand unbekannt ist.

Schreiben Sie das Ergebnis in drei Sätzen: die beobachtete Bedingung, die Komponente, die die Entscheidung durchsetzt, und der bewusste Rückfall. Fehlt eine der drei, ist die Regel noch keine Richtlinie; sie ist eine Vermutung, die im Büronetzwerk zufällig funktioniert.