A regra de firewall por SSID parou de filtrar após uma troca de Wi-Fi

A regra era simples: filtrar o tráfego apenas enquanto o telemóvel estivesse ligado ao Wi-Fi do escritório. Aguardou meses, e depois, numa manhã, o telemóvel estava no mesmo SSID com o mesmo ícone de chave e a filtragem tinha parado. Nada da rede tinha mudado; o que mudou foi se a aplicação conseguia ver o nome da rede. No Android, «em que Wi-Fi estou» e «bloqueia este tráfego» são duas tarefas separadas, e um firewall que as confunde falha aberto precisamente quando o nome deixa de estar disponível.

O sintoma: a identidade desaparece e a política segue-a

Uma regra por SSID lê um valor e depois escolhe um ramo. Quando a leitura não devolve nada de útil, o código tem de fazer alguma coisa, e o padrão habitual é «não é a rede esperada, portanto não filtrar». Esse padrão transforma um problema de permissões numa fuga de tráfego. O ícone da chave continua visível porque o serviço VPN ainda está a correr; está apenas a aplicar outro ramo.

Olhe para a ordem dos acontecimentos, não para a rede. Um pedido de permissão recusado, uma atualização do sistema que moveu o acesso ao SSID para trás de outra permissão, serviços de localização desligados ou uma alteração de política do perfil de trabalho podem todos produzir o mesmo resultado enquanto o telemóvel permanece no mesmo ponto de acesso.

Porque o nome pode voltar como desconhecido

WifiInfo.getSSID() devolve o identificador de conjunto de serviços da rede atual, e o Android documenta que o acesso a campos sensíveis à localização depende de permissão. Quando o acesso não está disponível, a chamada devolve UNKNOWN_SSID em vez de falhar ruidosamente. Um valor vazio ou desconhecido não é, por isso, prova de que o telemóvel saiu do Wi-Fi; é prova de que a aplicação não consegue classificar a rede.

Duas verificações separam os casos. Confirme que o telemóvel está associado e veja o que o sistema reporta, e depois confirme que a aplicação tem realmente a permissão de que precisa nesta versão do Android:

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

Se a linha de estado mostrar uma rede ligada enquanto a aplicação vê um nome desconhecido, tem um problema de permissões ou de nível de API, não um problema de Wi-Fi. Corrija isso antes de tocar nas regras do firewall, porque cada regra a jusante é avaliada contra um valor que a aplicação não consegue ler.

Onde a filtragem realmente corre

Um firewall local de Android usa normalmente o modelo VpnService sem enviar tráfego para um servidor remoto: pega na interface virtual, aplica as suas próprias regras e encaminha o que permite. A plataforma permite um serviço VPN ativo por perfil de utilizador, e um segundo substitui o primeiro em vez de se sobrepor a ele. Uma aplicação de firewall separada e uma VPN de trabalho separada não formam, por isso, uma cadeia de duas etapas; uma delas ganha.

Isso importa para uma regra por SSID porque o ponto de aplicação e o ponto de observação são componentes diferentes. O VpnService decide o que sai do dispositivo; a API de Wi-Fi fornece apenas um rótulo. Uma aplicação pode aplicar corretamente e classificar incorretamente, e é exatamente essa a falha neste artigo.

Dê ao desconhecido a sua própria política

Trate a identidade da rede como três estados e escreva a política de cada um antes de lançar a regra. O terceiro estado é o que se esquece, e é nele que um atacante ou uma configuração errada o vai colocar.

Falhar fechado significa que o estado desconhecido herda a política razoável mais estrita e não a mais conveniente. Se isso tornar o telemóvel inutilizável numa rede nova, a solução correta é uma exceção deliberada e visível, não uma decisão de confiança silenciosa escondida numa verificação de valor nulo.

Um SSID familiar é um rótulo, não uma prova do operador da rede. Qualquer pessoa pode montar um ponto de acesso com o nome do escritório, por isso uma correspondência de nome nunca deve ser a única coisa entre uma sessão sensível e um segmento não confiável.

Teste as transições, não o estado estável

Os testes em estado estável passam na rede onde construiu a regra. As falhas vivem nas transições: permissão negada, Wi-Fi para móvel, um SSID para outro, o serviço VPN reiniciado e outra aplicação VPN a assumir a interface. Para cada uma, decida se as ligações existentes são reconsideradas e se o tráfego protegido continua bloqueado enquanto o estado é desconhecido.

Escreva o resultado em três frases: a condição observada, o componente que aplica a decisão e o recuo deliberado. Se faltar alguma das três, a regra ainda não é uma política; é um palpite que funciona por acaso na rede do escritório.