A regra de firewall por SSID deixou de filtrar tras un cambio de Wi-Fi
Un firewall baseado no SSID falla aberto cando Android devolve un nome de rede descoñecido. Separa a identidade da aplicación e dálle ao descoñecido a súa propia política.
A regra era simple: filtrar o tráfico só mentres o teléfono estivese conectado ao Wi-Fi da oficina. Aguantou meses, e logo, unha mañá, o teléfono estaba no mesmo SSID coa mesma icona de chave e o filtrado parara. Nada da rede cambiara; o que cambiara era se a aplicación podía ver o nome da rede. En Android, «en que Wi-Fi estou» e «bloquea este tráfico» son dúas tarefas separadas, e un firewall que as confunde falla aberto xusto cando o nome deixa de estar dispoñible.
O síntoma: a identidade desaparece e a política séguena
Unha regra por SSID le un valor e despois escolle unha rama. Cando a lectura non devolve nada útil, o código ten que facer algo, e o defecto habitual é «non é a rede esperada, así que non filtres». Ese defecto converte un problema de permisos nunha fuga de tráfico. A icona da chave segue visible porque o servizo VPN continúa en execución; só está aplicando outra rama.
Mire a orde dos acontecementos, non a rede. Un diálogo de permiso rexeitado, unha actualización do sistema que moveu o acceso ao SSID detrás doutro permiso, os servizos de localización apagados ou un cambio de política do perfil de traballo poden producir o mesmo resultado mentres o teléfono segue no mesmo punto de acceso.
Por que o nome pode volver descoñecido
WifiInfo.getSSID() devolve o identificador de conxunto de servizos da rede actual, e Android documenta que o acceso aos campos sensibles á localización depende do permiso. Cando o acceso non está dispoñible, a chamada devolve UNKNOWN_SSID en lugar de fallar ruidosamente. Un valor baleiro ou descoñecido non é, polo tanto, proba de que o teléfono deixase o Wi-Fi; é proba de que a aplicación non pode clasificar a rede.
Dúas comprobacións separan os casos. Confirme que o teléfono está asociado e vexa que informa o sistema, e despois confirme que a aplicación ten realmente o permiso que precisa nesta versión de Android:
adb shell cmd wifi status
adb shell dumpsys package <your.app> | grep -i -E "ACCESS_FINE_LOCATION|NEARBY_WIFI_DEVICES"Se a liña de estado mostra unha rede conectada mentres a aplicación ve un nome descoñecido, ten un problema de permisos ou de nivel de API, non un problema de Wi-Fi. Corríxao antes de tocar as regras do firewall, porque cada regra posterior avalíase contra un valor que a aplicación non pode ler.
Onde se executa realmente o filtrado
Un firewall local de Android adoita usar o modelo VpnService sen enviar tráfico a un servidor remoto: toma a interface virtual, aplica as súas propias regras e reenvía o que permite. A plataforma permite un servizo VPN activo por perfil de usuario, e o segundo substitúe o primeiro en lugar de apilarse sobre el. Por iso unha aplicación de firewall separada e unha VPN de traballo separada non forman unha cadea de dúas etapas; unha das dúas gaña.
Iso importa para unha regra por SSID porque o punto de aplicación e o punto de observación son compoñentes distintos. O VpnService decide que sae do dispositivo; a API de Wi-Fi só achega unha etiqueta. Unha aplicación pode aplicar correctamente e clasificar incorrectamente, e ese é exactamente o fallo deste artigo.
Dálle ao descoñecido a súa propia política
Trate a identidade da rede como tres estados e escriba a política de cada un antes de publicar a regra. O terceiro estado é o que se esquece, e é no que lle vai pór un atacante ou unha configuración 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 pechado significa que o estado descoñecido herda a política razoable máis estrita en lugar da máis cómoda. Se iso deixa o teléfono inutilizable nunha rede nova, a solución correcta é unha excepción deliberada e visible, non unha decisión de confianza silenciosa agochada nunha comprobación de valor nulo.
Un SSID familiar é unha etiqueta, non unha proba do operador da rede. Calquera pode montar un punto de acceso co nome da oficina, así que unha coincidencia de nome nunca debería ser o único entre unha sesión sensible e un segmento non fiable.
Probe as transicións, non o estado estable
As probas en estado estable pasan na rede onde construíu a regra. Os fallos viven nas transicións: permiso denegado, de Wi-Fi a móbil, dun SSID a outro, o servizo VPN reiniciado e outra aplicación VPN que toma a interface. Para cada unha, decida se as conexións existentes se reconsideran e se o tráfico protexido permanece bloqueado mentres o estado é descoñecido.
Escriba o resultado en tres frases: a condición observada, o compoñente que aplica a decisión e o repliegue deliberado. Se falta calquera das tres, a regra aínda non é unha política; é unha suposición que funciona por casualidade na rede da oficina.