iPhoneのVPNアイコンが点灯：すべてのアプリをカバーしているのか、それとも動くだけなのか

バッジが表示されても、アプリは自宅にいるときと同じように動き続ける。そこで「トンネルが壊れている」と結論づけたくなる。だが多くの場合、壊れているものは何もない。バッジが報告するのは一つの接続であり、その背後にある問いはカバレッジについてだ。両者は別の主張である。

どの主張ができるかは三つの条件で決まる。それらが確定するまで、どんなテスト結果も曖昧なままだ。

一つのアイコンの裏に三つの答えがある

第一の問いは、トンネルに何をさせたかったのかという点だ。社内ウィキに到達すること、ストリーミングサービスから自分のアドレスを隠すこと、管理対象のアプリを一つ保護することは、それぞれ別の要件であり、別のプロファイルが満たす。

第二の問いは、そのプロファイルを誰が所有しているかだ。個人が自分でインストールした構成は、管理システムから配布されたものとは動作が異なる。後者だけが、iOSが適用するアプリ単位のルールを運ぶことができる。バッジはその二つを区別できない。

第三の問いは、どのアドレスファミリー上にいるかだ。ネットワークがIPv6を配布しているのにトンネルがIPv4を運ぶなら、一本の経路がトンネルの外に残る。IPv4のサイトにしか到達しないテストでは、それは決して見えない。

アプリ単位のプロファイルはそのアプリだけをカバーする

アプリ単位のVPNは、誤警報が最も多く出るケースだ。プロファイルはトンネルに入るトラフィックのアプリを指定し、それ以外は設計どおりローカルネットワークをそのまま使う。したがって、ブラウザで公開アドレスが変わらないのは想定された動作であり、失敗の証拠ではない。ステータスバーの表示と矛盾するものは何もない。

プロファイルが作られたアプリをテストし、内側にしか存在しないリソースに対してテストする。指定されたアプリからの内部リクエストが成功すれば、構成は機能している。そのうえでSafariで通常の公開アドレスが表示されるなら、アプリ単位のプロファイルは設定どおりに動作している。

オンデマンドのルールは観測結果を変える

オンデマンド構成が決めるのは、いつ接続を確立するかであり、トラフィックがカバーされるかどうかではない。特定のドメインが要求されたときにトンネルを立ち上げ、要求が終わると切断するルールもあり、日常利用でバッジが出たり消えたりするのは設計どおりの動作だ。バッジを解釈する前にルールを読むこと。

この挙動は、一日のうちで矛盾して見える結果も説明する。同じアプリが午前十時にはトンネルを通り、正午には直接通信になることがある。変わったのはポリシーではなくトリガー条件だ。

一度の検査はカバレッジの証明ではない

ブラウザでの検査一度が証明するのは、一つのリクエストが一つの経路を通ったということだけだ。独自のネットワークスタックを持つ二つ目のアプリ、トンネルが上がる前に走ったバックグラウンド同期、古いソケットが再確立されなかったためにネットワーク変更を生き延びた接続については何も語らない。その隙間は範囲の問題であり、漏れではない。

四行目だけが障害を示す。トンネルは接続しているのに名前解決が壊れている、戻り経路がない、サービスが単に停止しているという状況は、アプリから見れば同じに見える。

エスカレーション前に記録すべきこと

プロファイル名、管理システム由来かどうか、アプリ単位のルールの有無、失敗したリクエストの正確な時刻を書き留める。試したアドレスファミリーと、テストしたアプリも加える。画面の数字がこのリストの代わりになることはない。この記録があれば、カバレッジの疑問と障害を一往復で切り分けられる。

セキュリティの基本も忘れないこと。トンネルは証明書の検証、アカウントの保護、デバイスの権限の代わりにはならない。ネットワーク状態の横にアイコンが出ることは、それらが設定されている証拠ではない。バッジを根拠にプライバシーを主張するのは、まさにその取り違えだ。

AppleのVPN展開の概要には、プロファイルの種類と、こうした違いの背景にあるオンデマンドの動作が説明されている。プロファイルが何をカバーすべきかで管理システムと議論する前に、目を通しておきたい。