Wi-Fi切り替え後にSSIDファイアウォール規則がフィルタリングを停止した
Androidが未知のネットワーク名を返すと、SSIDに紐づいたファイアウォールは開いたまま失敗する。識別と適用を分離し、未知の状態に独自のポリシーを与える。
規則は単純だった。社内Wi-Fiに接続している間だけ通信をフィルタリングする。それは何ヶ月も機能していたが、ある朝、スマートフォンは同じSSIDに同じ鍵アイコンを出したまま、フィルタリングを止めていた。ネットワーク側に変化はない。変わったのは、アプリがネットワーク名を読めるかどうかだった。Androidでは「どのWi-Fiにいるか」と「この通信を止めるか」は別の仕事であり、両者を混同するファイアウォールは、名前が取れなくなったまさにその瞬間に開いてしまう。
症状 — 識別が消え、ポリシーがそれに従う
SSID規則は値を読み、その結果で分岐を選ぶ。読み取りが有用な値を返さないとき、コードは何かをしなければならず、よくある既定は「想定したネットワークではないのでフィルタしない」だ。この既定が、権限の問題を通信の漏えいに変える。鍵アイコンが見えたままなのはVPNサービスが動き続けているからで、単に別の分岐を実行しているだけだ。
ネットワークではなく、出来事の順序を見る。権限ダイアログの拒否、SSIDへのアクセスを別の権限の背後へ移したシステム更新、位置情報サービスの無効化、仕事用プロファイルのポリシー変更は、いずれも同じアクセスポイントに留まったまま同じ結果を生む。
名前が未知で返ってくる理由
WifiInfo.getSSID()は現在のネットワークのサービスセット識別子を返し、Androidは位置情報に関わるフィールドへのアクセスが権限に依存すると文書化している。アクセスがないとき、呼び出しは大きな失敗ではなくUNKNOWN_SSIDを返す。したがって空または未知の値は、端末がWi-Fiを離れた証拠ではない。アプリがネットワークを分類できない証拠である。
二つの確認が場合分けになる。端末が関連付けられていることを確かめてシステムの報告を見てから、このAndroidの版でアプリが必要な権限を実際に持っていることを確かめる。
adb shell cmd wifi status
adb shell dumpsys package <your.app> | grep -i -E "ACCESS_FINE_LOCATION|NEARBY_WIFI_DEVICES"
状態行が接続中のネットワークを示すのにアプリが未知の名前を見ているなら、それは権限かAPIレベルの問題であり、Wi-Fiの問題ではない。ファイアウォール規則に触れる前にこれを直すべきだ。後続のすべての規則は、アプリが読めない値に対して評価されているからだ。
フィルタリングが実際に動く場所
ローカルのAndroidファイアウォールは通常、通信を遠隔のサーバーへ送らずにVpnServiceモデルを使う。仮想インターフェースを受け取り、独自の規則を適用し、許可したものを転送する。プラットフォームはユーザープロファイルごとに一つのVPNサービスしか同時に動かせず、二つ目は一つ目の上に重なるのではなく置き換える。したがって別々のファイアウォールアプリと仕事用VPNは二段の鎖にならず、どちらか一方が勝つ。
これがSSID規則で重要になるのは、適用の点と観測の点が別の部品だからだ。VpnServiceが端末から何を出すかを決め、Wi-FiのAPIはラベルを渡すだけである。アプリは正しく適用しながら誤って分類でき、それがこの記事の障害そのものだ。
未知に独自のポリシーを与える
ネットワークの識別を三つの状態として扱い、規則を出す前にそれぞれのポリシーを書き下す。忘れられるのは三つ目の状態であり、攻撃者や設定ミスがあなたを置くのはそこだ。
| 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 |
閉じた失敗とは、未知の状態が最も都合のよいポリシーではなく、最も厳しい妥当なポリシーを引き継ぐことだ。そのせいで新しいネットワークで端末が使えなくなるなら、正しい対処は意図的で見える例外であり、空値の検査に隠れた黙った信頼の判断ではない。
見慣れたSSIDはラベルであり、ネットワーク事業者の証明ではない。誰でも社名のアクセスポイントを立てられるので、名前の一致だけが機密セッションと信頼できない区間の間の唯一の壁であってはならない。
定常状態ではなく遷移を試す
定常状態の試験は、規則を組み立てたネットワークで通る。障害は遷移に住む。権限拒否、Wi-Fiからモバイルへ、あるSSIDから別のSSIDへ、VPNサービスの再起動、別のVPNアプリによるインターフェースの奪取である。それぞれについて、既存の接続を見直すか、状態が未知の間も保護対象の通信を遮断し続けるかを決める。
結果を三つの文で書く。観測した条件、判断を適用する部品、意図した代替動作である。三つのどれかが欠けているなら、その規則はまだポリシーではない。社内ネットワークでたまたま動く推測にすぎない。