La regla de tallafocs per SSID va deixar de filtrar després d’un canvi de Wi-Fi
Un tallafocs basat en SSID falla obert quan Android retorna un nom de xarxa desconegut. Separa la identitat de l’aplicació i dona a la incògnita la seva pròpia política.
La regla era simple: filtra el trànsit només mentre estiguis connectat al Wi-Fi de l’oficina. Va aguantar mesos, i després, un matí, el telèfon era a la mateixa SSID amb la mateixa icona de clau i el filtratge s’havia aturat. No havia canviat res de la xarxa; el que havia canviat era si l’aplicació podia veure el nom de la xarxa. A Android, «a quin Wi-Fi sóc» i «bloca aquest trànsit» són dues feines separades, i un tallafocs que les confon falla obert exactament quan el nom deixa d’estar disponible.
El símptoma: la identitat desapareix i la política la segueix
Una regla per SSID llegeix un valor i després tria una branca. Quan la lectura no retorna res d’útil, el codi ha de fer alguna cosa, i el defecte habitual és «no és la xarxa esperada, així que no filtris». Aquest defecte converteix un problema de permisos en una fuita de trànsit. La icona de la clau continua visible perquè el servei VPN encara s’executa; només està aplicant una altra branca.
Mireu l’ordre dels esdeveniments, no la xarxa. Un diàleg de permís refusat, una actualització del sistema que va moure l’accés a la SSID darrere d’un altre permís, els serveis d’ubicació apagats o un canvi de política del perfil de treball poden produir el mateix resultat mentre el telèfon es queda al mateix punt d’accés.
Per què el nom pot tornar desconegut
WifiInfo.getSSID() retorna l’identificador de conjunt de serveis de la xarxa actual, i Android documenta que l’accés als camps sensibles a la ubicació depèn del permís. Quan l’accés no està disponible, la crida retorna UNKNOWN_SSID en lloc de fallar sorollosament. Un valor buit o desconegut, doncs, no és prova que el telèfon hagi deixat el Wi-Fi; és prova que l’aplicació no pot classificar la xarxa.
Dues comprovacions separen els casos. Confirmeu que el telèfon està associat i mireu què informa el sistema, i després confirmeu que l’aplicació té realment el permís que necessita en aquesta versió d’Android:
adb shell cmd wifi status
adb shell dumpsys package <your.app> | grep -i -E "ACCESS_FINE_LOCATION|NEARBY_WIFI_DEVICES"Si la línia d’estat mostra una xarxa connectada mentre l’aplicació veu un nom desconegut, teniu un problema de permisos o de nivell d’API, no un problema de Wi-Fi. Arregleu-ho abans de tocar les regles del tallafocs, perquè cada regla posterior s’avalua contra un valor que l’aplicació no pot llegir.
On s’executa realment el filtratge
Un tallafocs local d’Android normalment fa servir el model VpnService sense enviar trànsit a un servidor remot: pren la interfície virtual, aplica les seves pròpies regles i reenvia el que permet. La plataforma permet un servei VPN actiu per perfil d’usuari, i el segon substitueix el primer en lloc d’apilar-s’hi. Per tant, una aplicació de tallafocs separada i una VPN de feina separada no formen una cadena de dues etapes; una de les dues guanya.
Això importa per a una regla per SSID perquè el punt d’aplicació i el punt d’observació són components diferents. El VpnService decideix què surt del dispositiu; l’API de Wi-Fi només proporciona una etiqueta. Una aplicació pot aplicar correctament i classificar incorrectament, i aquesta és exactament la fallada d’aquest article.
Dona a la incògnita la seva pròpia política
Tracteu la identitat de la xarxa com a tres estats i escriviu la política de cadascun abans de publicar la regla. El tercer estat és el que s’oblida, i és on us posarà un atacant o una configuració incorrecta.
| 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 |
Fallar tancat vol dir que l’estat desconegut hereta la política raonable més estricta en lloc de la més convenient. Si això fa que el telèfon sigui inutilitzable en una xarxa nova, la solució correcta és una excepció deliberada i visible, no una decisió de confiança silenciosa amagada en una comprovació de valor nul.
Una SSID familiar és una etiqueta, no una prova de l’operador de la xarxa. Qualsevol pot muntar un punt d’accés amb el nom de l’oficina, així que una coincidència de nom no hauria de ser mai l’única cosa entre una sessió sensible i un segment no fiable.
Proveu les transicions, no l’estat estable
La prova en estat estable passa a la xarxa on vau construir la regla. Les fallades viuen en les transicions: permís denegat, de Wi-Fi a mòbil, d’una SSID a una altra, el servei VPN reiniciat i una altra aplicació VPN que pren la interfície. Per a cadascuna, decidiu si les connexions existents es reconsideren i si el trànsit protegit continua bloquejat mentre l’estat és desconegut.
Escriviu el resultat en tres frases: la condició observada, el component que aplica la decisió i el retrocés deliberat. Si falta qualsevol de les tres, la regla encara no és una política; és una suposició que funciona per casualitat a la xarxa de l’oficina.