La regla de firewall por SSID dejó de filtrar tras un cambio de Wi-Fi

La regla era sencilla: filtrar el tráfico solo mientras el teléfono estuviera conectado al Wi-Fi de la oficina. Aguantó meses, y luego, una mañana, el teléfono estaba en la misma SSID con el mismo icono de llave y el filtrado se había detenido. Nada de la red había cambiado; lo que había cambiado era si la aplicación podía ver el nombre de la red. En Android, «en qué Wi-Fi estoy» y «bloquea este tráfico» son dos tareas separadas, y un firewall que las confunde falla abierto justo cuando el nombre deja de estar disponible.

El síntoma: la identidad desaparece y la política la sigue

Una regla por SSID lee un valor y luego elige una rama. Cuando la lectura no devuelve nada útil, el código tiene que hacer algo, y el valor por defecto habitual es «no es la red esperada, así que no filtres». Ese valor por defecto convierte un problema de permisos en una fuga de tráfico. El icono de la llave sigue visible porque el servicio VPN continúa ejecutándose; solo está aplicando otra rama.

Mire el orden de los acontecimientos, no la red. Un diálogo de permiso rechazado, una actualización del sistema que movió el acceso a la SSID detrás de otro permiso, los servicios de ubicación apagados o un cambio de política del perfil de trabajo pueden producir el mismo resultado mientras el teléfono sigue en el mismo punto de acceso.

Por qué el nombre puede volver como desconocido

WifiInfo.getSSID() devuelve el identificador de conjunto de servicios de la red actual, y Android documenta que el acceso a los campos sensibles a la ubicación depende del permiso. Cuando el acceso no está disponible, la llamada devuelve UNKNOWN_SSID en lugar de fallar de forma ruidosa. Un valor vacío o desconocido no es, por tanto, prueba de que el teléfono haya dejado el Wi-Fi; es prueba de que la aplicación no puede clasificar la red.

Dos comprobaciones separan los casos. Confirme que el teléfono está asociado y vea qué informa el sistema, y luego confirme que la aplicación tiene realmente el permiso que necesita en esta versión de Android:

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

Si la línea de estado muestra una red conectada mientras la aplicación ve un nombre desconocido, tiene un problema de permisos o de nivel de API, no un problema de Wi-Fi. Corríjalo antes de tocar las reglas del firewall, porque cada regla posterior se evalúa contra un valor que la aplicación no puede leer.

Dónde se ejecuta realmente el filtrado

Un firewall local de Android suele usar el modelo VpnService sin enviar tráfico a un servidor remoto: toma la interfaz virtual, aplica sus propias reglas y reenvía lo que permite. La plataforma permite un servicio VPN activo por perfil de usuario, y el segundo sustituye al primero en lugar de apilarse sobre él. Por eso una aplicación de firewall separada y una VPN de trabajo separada no forman una cadena de dos etapas; una de las dos gana.

Eso importa para una regla por SSID porque el punto de aplicación y el punto de observación son componentes distintos. El VpnService decide qué sale del dispositivo; la API de Wi-Fi solo aporta una etiqueta. Una aplicación puede aplicar correctamente y clasificar incorrectamente, y ese es exactamente el fallo de este artículo.

Da al caso desconocido su propia política

Trate la identidad de la red como tres estados y escriba la política de cada uno antes de publicar la regla. El tercer estado es el que se olvida, y es en el que le pondrá un atacante o una configuración incorrecta.

Fallar cerrado significa que el estado desconocido hereda la política razonable más estricta en lugar de la más cómoda. Si eso deja el teléfono inutilizable en una red nueva, la solución correcta es una excepción deliberada y visible, no una decisión de confianza silenciosa escondida en una comprobación de valor nulo.

Una SSID familiar es una etiqueta, no una prueba del operador de la red. Cualquiera puede montar un punto de acceso con el nombre de la oficina, así que una coincidencia de nombre nunca debería ser lo único entre una sesión sensible y un segmento no confiable.

Pruebe las transiciones, no el estado estable

Las pruebas en estado estable pasan en la red donde construyó la regla. Los fallos viven en las transiciones: permiso denegado, de Wi-Fi a móvil, de una SSID a otra, el servicio VPN reiniciado y otra aplicación VPN que toma la interfaz. Para cada una, decida si las conexiones existentes se reconsideran y si el tráfico protegido permanece bloqueado mientras el estado es desconocido.

Escriba el resultado en tres frases: la condición observada, el componente que aplica la decisión y el repliegue deliberado. Si falta cualquiera de las tres, la regla aún no es una política; es una suposición que funciona por casualidad en la red de la oficina.