La regola del firewall per SSID ha smesso di filtrare dopo un cambio di Wi-Fi

La regola era semplice: filtrare il traffico solo mentre il telefono è connesso al Wi-Fi dell’ufficio. Ha tenuto per mesi, poi una mattina il telefono era sulla stessa SSID con la stessa icona della chiave e il filtraggio si era fermato. Nulla della rete era cambiato; ciò che era cambiato era se l’app potesse vedere il nome della rete. Su Android, «a quale Wi-Fi sono» e «blocca questo traffico» sono due compiti separati, e un firewall che li confonde fallisce aperto proprio quando il nome non è più disponibile.

Il sintomo: l’identità sparisce e la politica la segue

Una regola per SSID legge un valore e poi sceglie un ramo. Quando la lettura non restituisce nulla di utile, il codice deve fare qualcosa, e il valore predefinito abituale è «non è la rete attesa, quindi non filtrare». Quel valore predefinito trasforma un problema di permessi in una fuga di traffico. L’icona della chiave resta visibile perché il servizio VPN è ancora in esecuzione; sta solo applicando un altro ramo.

Guarda l’ordine degli eventi, non la rete. Una richiesta di permesso rifiutata, un aggiornamento di sistema che ha spostato l’accesso all’SSID dietro un altro permesso, i servizi di localizzazione spenti o un cambiamento di politica del profilo di lavoro possono tutti produrre lo stesso risultato mentre il telefono resta sullo stesso punto di accesso.

Perché il nome può tornare sconosciuto

WifiInfo.getSSID() restituisce l’identificatore del set di servizi della rete corrente, e Android documenta che l’accesso ai campi sensibili alla posizione dipende dal permesso. Quando l’accesso non è disponibile, la chiamata restituisce UNKNOWN_SSID invece di fallire in modo rumoroso. Un valore vuoto o sconosciuto non è quindi prova che il telefono abbia lasciato il Wi-Fi; è prova che l’app non riesce a classificare la rete.

Due controlli separano i casi. Conferma che il telefono sia associato e guarda cosa riporta il sistema, poi conferma che l’app possieda davvero il permesso che le serve su questa versione di Android:

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

Se la riga di stato mostra una rete connessa mentre l’app vede un nome sconosciuto, hai un problema di permessi o di livello API, non un problema di Wi-Fi. Correggilo prima di toccare le regole del firewall, perché ogni regola a valle viene valutata rispetto a un valore che l’app non può leggere.

Dove viene eseguito davvero il filtraggio

Un firewall Android locale usa di norma il modello VpnService senza inviare il traffico a un server remoto: prende l’interfaccia virtuale, applica le proprie regole e inoltra ciò che consente. La piattaforma permette un solo servizio VPN attivo per profilo utente, e il secondo sostituisce il primo invece di sovrapporsi. Un’app firewall separata e una VPN di lavoro separata non formano quindi una catena a due stadi; una delle due vince.

Questo conta per una regola per SSID perché il punto di applicazione e il punto di osservazione sono componenti diversi. Il VpnService decide cosa esce dal dispositivo; l’API Wi-Fi fornisce solo un’etichetta. Un’app può applicare correttamente e classificare in modo errato, ed è esattamente il guasto di questo articolo.

Dai allo sconosciuto una politica propria

Tratta l’identità della rete come tre stati e scrivi la politica di ciascuno prima di rilasciare la regola. Il terzo stato è quello che si dimentica, ed è quello in cui ti metterà un attaccante o una configurazione errata.

Fallire chiuso significa che lo stato sconosciuto eredita la politica ragionevole più rigorosa invece di quella più comoda. Se questo rende il telefono inutilizzabile su una rete nuova, la soluzione corretta è un’eccezione deliberata e visibile, non una decisione di fiducia silenziosa nascosta in un controllo su valore nullo.

Un SSID familiare è un’etichetta, non una prova dell’operatore della rete. Chiunque può avviare un punto di accesso con il nome dell’ufficio, quindi una corrispondenza di nome non dovrebbe mai essere l’unica cosa tra una sessione sensibile e un segmento non fidato.

Metti alla prova le transizioni, non lo stato stabile

I test in stato stabile passano sulla rete dove hai costruito la regola. I guasti vivono nelle transizioni: permesso negato, da Wi-Fi a mobile, da un SSID a un altro, servizio VPN riavviato e un’altra app VPN che prende l’interfaccia. Per ciascuna, decidi se le connessioni esistenti vengono riconsiderate e se il traffico protetto resta bloccato mentre lo stato è sconosciuto.

Scrivi il risultato in tre frasi: la condizione osservata, il componente che applica la decisione e il ripiego deliberato. Se manca una delle tre, la regola non è ancora una politica; è una supposizione che funziona per caso sulla rete dell’ufficio.