La règle de pare-feu par SSID a cessé de filtrer après un changement de Wi-Fi

La règle était simple : filtrer le trafic seulement pendant que le téléphone était connecté au Wi-Fi du bureau. Elle a tenu des mois, puis un matin le téléphone se trouvait sur le même SSID avec la même icône de clé et le filtrage s’était arrêté. Rien n’avait changé sur le réseau ; ce qui avait changé, c’était que l’application pouvait ou non voir le nom du réseau. Sous Android, « sur quel Wi-Fi suis-je » et « bloque ce trafic » sont deux tâches distinctes, et un pare-feu qui les confond échoue ouvert précisément quand le nom devient indisponible.

Le symptôme : l’identité disparaît, la politique suit

Une règle par SSID lit une valeur puis choisit une branche. Quand la lecture ne renvoie rien d’utile, le code doit faire quelque chose, et le défaut courant est « ce n’est pas le réseau attendu, donc ne filtre pas ». Ce défaut transforme un problème de permission en fuite de trafic. L’icône de clé reste visible parce que le service VPN tourne encore ; il applique simplement une autre branche.

Regardez l’ordre des événements, pas le réseau. Une demande de permission refusée, une mise à jour système qui a déplacé l’accès au SSID derrière une autre permission, les services de localisation désactivés ou un changement de politique du profil professionnel peuvent tous produire le même résultat alors que le téléphone reste sur le même point d’accès.

Pourquoi le nom peut revenir inconnu

WifiInfo.getSSID() renvoie l’identifiant d’ensemble de services du réseau courant, et Android documente que l’accès aux champs sensibles à la localisation dépend d’une permission. Quand l’accès n’est pas disponible, l’appel renvoie UNKNOWN_SSID au lieu d’échouer bruyamment. Une valeur vide ou inconnue n’est donc pas la preuve que le téléphone a quitté le Wi-Fi ; c’est la preuve que l’application ne peut pas classer le réseau.

Deux vérifications séparent les cas. Confirmez que le téléphone est associé et regardez ce que le système rapporte, puis confirmez que l’application détient réellement la permission dont elle a besoin sur cette version d’Android :

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

Si la ligne d’état montre un réseau connecté alors que l’application voit un nom inconnu, vous avez un problème de permission ou de niveau d’API, pas un problème de Wi-Fi. Corrigez-le avant de toucher aux règles du pare-feu, car chaque règle en aval est évaluée contre une valeur que l’application ne peut pas lire.

Où le filtrage s’exécute réellement

Un pare-feu Android local utilise normalement le modèle VpnService sans envoyer le trafic vers un serveur distant : il prend l’interface virtuelle, applique ses propres règles et relaie ce qu’il autorise. La plateforme autorise un seul service VPN actif par profil utilisateur, et un second remplace le premier au lieu de s’empiler dessus. Une application de pare-feu séparée et un VPN professionnel séparé ne forment donc pas une chaîne à deux étages ; l’un des deux l’emporte.

Cela compte pour une règle par SSID parce que le point d’application et le point d’observation sont des composants différents. Le VpnService décide de ce qui quitte l’appareil ; l’API Wi-Fi ne fournit qu’une étiquette. Une application peut appliquer correctement et classer incorrectement, et c’est exactement la défaillance de cet article.

Donnez à l’inconnu sa propre politique

Traitez l’identité du réseau comme trois états et écrivez la politique de chacun avant de livrer la règle. Le troisième état est celui qu’on oublie, et c’est celui où vous placera un attaquant ou une mauvaise configuration.

Échouer fermé signifie que l’état inconnu hérite de la politique raisonnable la plus stricte plutôt que de la plus commode. Si cela rend le téléphone inutilisable sur un nouveau réseau, la bonne solution est une exception délibérée et visible, pas une décision de confiance silencieuse cachée dans un test de valeur nulle.

Un SSID familier est une étiquette, pas une preuve de l’opérateur du réseau. N’importe qui peut monter un point d’accès avec le nom du bureau, donc une correspondance de nom ne devrait jamais être la seule chose entre une session sensible et un segment non fiable.

Testez les transitions, pas l’état stable

Les tests en état stable passent sur le réseau où vous avez construit la règle. Les défaillances vivent dans les transitions : permission refusée, Wi-Fi vers mobile, un SSID vers un autre, service VPN redémarré et une autre application VPN qui prend l’interface. Pour chacune, décidez si les connexions existantes sont réévaluées et si le trafic protégé reste bloqué tant que l’état est inconnu.

Écrivez le résultat en trois phrases : la condition observée, le composant qui applique la décision et le repli délibéré. Si l’une des trois manque, la règle n’est pas encore une politique ; c’est une supposition qui fonctionne par hasard sur le réseau du bureau.