Reguła firewalla oparta na SSID przestała filtrować po zmianie Wi-Fi
Firewall powiązany z SSID zawodzi otwarcie, gdy Android zwraca nieznaną nazwę sieci. Oddziel tożsamość od egzekwowania i daj nieznanemu własną politykę.
Reguła była prosta: filtruj ruch tylko wtedy, gdy telefon jest połączony z Wi-Fi biura. Działała miesiącami, a potem pewnego ranka telefon siedział w tej samej SSID z tą samą ikoną klucza, a filtrowanie ustało. W sieci nic się nie zmieniło; zmieniło się to, czy aplikacja widzi nazwę sieci. W Androidzie „w jakiej Wi-Fi jestem” i „zablokuj ten ruch” to dwa osobne zadania, a firewall, który je miesza, zawodzi otwarcie dokładnie wtedy, gdy nazwa staje się niedostępna.
Objaw: tożsamość znika, a polityka idzie za nią
Reguła SSID czyta wartość, a następnie wybiera gałąź. Gdy odczyt nie zwraca nic użytecznego, kod musi coś zrobić, a typowa wartość domyślna to „to nie oczekiwana sieć, więc nie filtruj”. To zamienia problem uprawnień w wyciek ruchu. Ikona klucza pozostaje widoczna, bo usługa VPN nadal działa; po prostu egzekwuje inną gałąź.
Patrz na kolejność zdarzeń, nie na sieć. Odrzucone okno uprawnień, aktualizacja systemu, która przeniosła dostęp do SSID za inne uprawnienie, wyłączone usługi lokalizacji albo zmiana polityki profilu służbowego mogą dać ten sam wynik, podczas gdy telefon pozostaje w tym samym punkcie dostępowym.
Dlaczego nazwa może wrócić jako nieznana
WifiInfo.getSSID() zwraca identyfikator zestawu usług bieżącej sieci, a Android dokumentuje, że dostęp do pól wrażliwych na lokalizację zależy od uprawnienia. Gdy dostęp jest niedostępny, wywołanie zwraca UNKNOWN_SSID zamiast głośno zawodzić. Pusta lub nieznana wartość nie jest więc dowodem, że telefon opuścił Wi-Fi; jest dowodem, że aplikacja nie potrafi sklasyfikować sieci.
Dwie kontrole rozdzielają przypadki. Potwierdź, że telefon jest połączony, i zobacz, co raportuje system, a następnie potwierdź, że aplikacja naprawdę ma uprawnienie potrzebne w tej wersji Androida:
adb shell cmd wifi status
adb shell dumpsys package <your.app> | grep -i -E "ACCESS_FINE_LOCATION|NEARBY_WIFI_DEVICES"Jeśli linia stanu pokazuje połączoną sieć, a aplikacja widzi nieznaną nazwę, masz problem z uprawnieniami lub na poziomie API, a nie problem z Wi-Fi. Napraw to, zanim dotkniesz reguł firewalla, bo każda kolejna reguła jest oceniana względem wartości, której aplikacja nie może odczytać.
Gdzie filtrowanie faktycznie działa
Lokalny firewall Androida zwykle korzysta z modelu VpnService bez wysyłania ruchu do zdalnego serwera: bierze interfejs wirtualny, stosuje własne reguły i przekazuje to, co dopuszcza. Platforma pozwala na jedną aktywną usługę VPN na profil użytkownika, a druga zastępuje pierwszą, zamiast nakładać się na nią. Osobna aplikacja firewalla i osobny VPN służbowy nie tworzą więc dwustopniowego łańcucha; jedno z nich wygrywa.
Ma to znaczenie dla reguły SSID, ponieważ punkt egzekwowania i punkt obserwacji to różne komponenty. VpnService decyduje, co opuszcza urządzenie; API Wi-Fi dostarcza tylko etykietę. Aplikacja może egzekwować poprawnie i klasyfikować błędnie, i dokładnie tym jest awaria w tym artykule.
Daj nieznanemu własną politykę
Traktuj tożsamość sieci jako trzy stany i zapisz politykę dla każdego z nich, zanim wydasz regułę. Trzeci stan to ten, o którym się zapomina, i w nim umieści cię atakujący albo błędna konfiguracja.
| 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 |
Zawodzić zamknięcie oznacza, że nieznany stan dziedziczy najostrzejszą rozsądną politykę, a nie najwygodniejszą. Jeśli przez to telefon staje się bezużyteczny w nowej sieci, właściwym rozwiązaniem jest świadomy, widoczny wyjątek, a nie cicha decyzja o zaufaniu ukryta w sprawdzeniu pustej wartości.
Znany SSID to etykieta, nie dowód operatora sieci. Każdy może uruchomić punkt dostępowy z nazwą biura, więc zgodność nazwy nigdy nie powinna być jedyną rzeczą między wrażliwą sesją a niezaufanym segmentem.
Testuj przejścia, nie stan ustalony
Testy w stanie ustalonym przechodzą w sieci, w której zbudowałeś regułę. Awarie żyją w przejściach: odmówione uprawnienie, Wi-Fi do sieci komórkowej, jedna SSID do drugiej, ponownie uruchomiona usługa VPN i inna aplikacja VPN przejmująca interfejs. Dla każdego zdecyduj, czy istniejące połączenia są ponownie oceniane i czy chroniony ruch pozostaje zablokowany, dopóki stan jest nieznany.
Zapisz wynik w trzech zdaniach: zaobserwowany warunek, komponent egzekwujący decyzję i świadomy wariant zapasowy. Jeśli brakuje któregoś z trzech, reguła nie jest jeszcze polityką; to domysł, który przypadkiem działa w sieci biurowej.