VPN アプリが起動する前に kill switch は通信を遮断するのか

kill switch がアプリ起動前の時間帯を覆うかどうかは、クライアントの宣伝ページではなくオペレーティングシステムのポリシーで決まります。自動起動のチェックボックスは、何かが起動するよう予定されていることの証拠にすぎません。ネットワークが立ち上がる瞬間に遮断ルールが存在することの証拠にはなりません。これは二つの出来事であり、通信を守るのはそのうち一方だけです。

チェックリストは順番に進めてください。各手順は、実際に何を検証しているのかを狭めていきます。

遮断は実際どこから来るのか

実装には二つの系統があります。アプリが動き出す前にトンネルを把握しているプラットフォームが遮断を仕込むか、あるいは クライアントが起動後に自ら遮断を仕込むかです。前者はログイン前から存在できます。後者は自分のプロセスより前には存在できません。そのプロセスがどれほど早く予定されていても同じです。何かを検証する前に、どちらの系統に頼っているのかを特定してください。

Android では、常時接続 VPN と VPN なしの接続を遮断する設定の組み合わせがプラットフォームのポリシーであり、クライアント内だけでなくシステム設定で構成します。管理された端末ではあらかじめ設定されていることもあります。単に起動時に立ち上がるだけのクライアントは、同じ仕組みではありません。

時間帯とサービスを分けて考える

閉じた時間帯は遮断が止まった証拠ではなく、開いた時間帯はトンネルの準備ができた証拠でもありません。多くのクライアントは画面、デーモン、常駐アプリを分けています。常駐アプリは目に見える部分であり、デーモンはルールを保持する部分です。

アイコンではなくコンポーネントを検証してください。

起動の時間帯を安全に検証する

検証する時間帯は再起動またはログインから始まり、トンネルが認証した時点で終わります。その間にはバックグラウンドのアプリが接続し、更新確認が常連の犯人です。自分のアクセスを遮断するのではなく、無害な通信とベンダーが文書化した手順を使ってください。そのうえで通常の再接続のあとに繰り返します。再接続の経路とコールドスタートの経路は別のコードを実行するからです。

トンネルがすでに立ち上がったあとに行う検証は、起動について何も証明しません。

永続性が要件なら、再起動時の挙動を読み取ってください。設定は構成に残ったまま、その適用が後から始まることがあり、両方の事実が重要です。保存されたポリシーと、それが有効になる瞬間です。

プラットフォームごとにポリシーを読む

Android は常時接続と遮断を別々のスイッチとして公開しており、起動前の保護には両方がオンである必要があります。Windows にはポリシーで構成する常時接続のデバイストンネルという考え方があり、これは早く起動するユーザーモードのクライアントとは同じものではありません。OpenVPN Connect はプラットフォームごとの kill switch の挙動を文書化しており、その文書化された範囲が検証対象です。設定名をあるシステムから別のシステムへ持ち込み、意味も一緒に移動したと仮定しないでください。

対話式パスワードを要求するプロファイルは、マシントンネルとは起動時の依存関係が異なります。

何を記録するか

どの仕組みが有効か、どの段階で有効になるか、その段階より前にどの通信を試したかを書き留めてください。プラットフォームのバージョンも記録します。この挙動はリリース間で、また管理構成と個人構成の間で変わるからです。ポリシーを所有するのがクライアントかシステムかも記します。隙間を誰が直せるかがこれで決まるからです。そのうえで、クライアントや OS の更新のたびに再検証してください。

隙間が重要なら、恒久的な解決はプラットフォームのポリシーであり、起動遅延を短くすることではありません。

これが元の問いへの答えです。条件として述べるなら、kill switch がアプリ起動前に通信を守るのは、アプリより前に存在する何かが遮断を仕込んでいる場合だけです。