Regula de firewall pe bază de SSID a încetat să mai filtreze după o schimbare de Wi-Fi

Regula era simplă: filtrează traficul doar cât timp telefonul este conectat la Wi-Fi-ul biroului. A rezistat luni întregi, apoi într-o dimineață telefonul stătea pe același SSID cu aceeași pictogramă de cheie, iar filtrarea se oprise. Nimic din rețea nu se schimbase; ce se schimbase era dacă aplicația putea vedea numele rețelei. În Android, „pe ce Wi-Fi sunt” și „blochează acest trafic” sunt două sarcini separate, iar un firewall care le confundă eșuează deschis exact când numele devine indisponibil.

Simptomul: identitatea dispare, iar politica o urmează

O regulă pe SSID citește o valoare și apoi alege o ramură. Când citirea nu returnează nimic util, codul trebuie să facă ceva, iar valoarea implicită obișnuită este „nu este rețeaua așteptată, deci nu filtra”. Această valoare implicită transformă o problemă de permisiuni într-o scurgere de trafic. Pictograma cheii rămâne vizibilă pentru că serviciul VPN încă rulează; doar aplică altă ramură.

Priviți ordinea evenimentelor, nu rețeaua. Un dialog de permisiune refuzat, o actualizare de sistem care a mutat accesul la SSID în spatele altei permisiuni, serviciile de locație oprite sau o schimbare de politică a profilului de lucru pot produce toate același rezultat în timp ce telefonul rămâne pe același punct de acces.

De ce numele poate reveni ca necunoscut

WifiInfo.getSSID() returnează identificatorul setului de servicii al rețelei curente, iar Android documentează că accesul la câmpurile sensibile la locație depinde de permisiune. Când accesul nu este disponibil, apelul returnează UNKNOWN_SSID în loc să eșueze zgomotos. O valoare goală sau necunoscută nu este, așadar, dovada că telefonul a părăsit Wi-Fi-ul; este dovada că aplicația nu poate clasifica rețeaua.

Două verificări separă cazurile. Confirmați că telefonul este asociat și vedeți ce raportează sistemul, apoi confirmați că aplicația deține într-adevăr permisiunea de care are nevoie pe această versiune de Android:

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

Dacă linia de stare arată o rețea conectată în timp ce aplicația vede un nume necunoscut, aveți o problemă de permisiuni sau de nivel API, nu o problemă de Wi-Fi. Remediați-o înainte de a atinge regulile firewallului, pentru că fiecare regulă ulterioară este evaluată față de o valoare pe care aplicația nu o poate citi.

Unde rulează de fapt filtrarea

Un firewall Android local folosește de obicei modelul VpnService fără a trimite traficul către un server îndepărtat: preia interfața virtuală, aplică propriile reguli și transmite ceea ce permite. Platforma permite un singur serviciu VPN activ per profil de utilizator, iar al doilea îl înlocuiește pe primul în loc să se suprapună. O aplicație de firewall separată și un VPN de lucru separat nu formează deci un lanț în două etape; unul dintre ele câștigă.

Asta contează pentru o regulă pe SSID pentru că punctul de aplicare și punctul de observare sunt componente diferite. VpnService decide ce părăsește dispozitivul; API-ul Wi-Fi oferă doar o etichetă. O aplicație poate aplica corect și clasifica incorect, iar aceasta este exact defecțiunea din acest articol.

Dă necunoscutului propria politică

Tratați identitatea rețelei ca trei stări și scrieți politica fiecăreia înainte de a livra regula. A treia stare este cea uitată, iar acolo vă va pune un atacator sau o configurație greșită.

A eșua închis înseamnă că starea necunoscută moștenește cea mai strictă politică rezonabilă, nu pe cea mai comodă. Dacă asta face telefonul inutilizabil pe o rețea nouă, soluția corectă este o excepție deliberată și vizibilă, nu o decizie tacită de încredere ascunsă într-o verificare de valoare nulă.

Un SSID familiar este o etichetă, nu o dovadă a operatorului rețelei. Oricine poate rula un punct de acces cu numele biroului, așa că o potrivire de nume nu ar trebui să fie niciodată singurul lucru între o sesiune sensibilă și un segment neîncrezut.

Testați tranzițiile, nu starea stabilă

Testele în stare stabilă trec pe rețeaua pe care ați construit regula. Defecțiunile trăiesc în tranziții: permisiune refuzată, de la Wi-Fi la mobil, de la un SSID la altul, serviciul VPN repornit și o altă aplicație VPN care preia interfața. Pentru fiecare, decideți dacă conexiunile existente sunt reevaluate și dacă traficul protejat rămâne blocat cât timp starea este necunoscută.

Scrieți rezultatul în trei propoziții: condiția observată, componenta care aplică decizia și replierea deliberată. Dacă lipsește vreuna dintre cele trei, regula nu este încă o politică; este o presupunere care funcționează din întâmplare pe rețeaua biroului.