端末の VPN マーカーと出口アドレス：どちらが何を証明するのか
端末で読むネットワークマーカーとサーバーが見るアドレスは別の証拠です。あなたの問いにどちらが必要かを決めてください。
スマートフォンのアプリと遠隔のサーバーは別々の事実から出発し、どちらも相手の事実を借りることはできません。アプリは自分が使うネットワークについて OS に問い合わせられますが、サーバーが知るのは接続の上に届いたものだけです。自分のエンドポイントを動かすと二つ目は書き換わり、一つ目は変わりません。どちらがあなたの問いに答えるかは、問いそのものが決めます。
二つの観測点、二種類の証拠
ローカルの証拠は端末を記述します。通信を運ぶインターフェース、プラットフォームが報告するトランスポート、呼び出したアプリが照会できる範囲を含みます。遠隔の証拠は接続を記述します。送信元アドレス、プロトコル、タイミング、そしてアプリが送ると決めたものです。どの観測点も他の観測点の上位集合ではありません。
両者を混ぜると、正確に聞こえて検証できない主張が生まれます。マーカーが証明するのは端末上のネットワークオブジェクトについてであり、遠隔のサービスが要求をどう分類するかではありません。
検出を論じる前に、その問いがどちらの点に関わるかを書き出してください。特定のアプリがトンネルの稼働を察知できるかという問いと、サービスが要求の出所を推測できるかという問いは別です。別々の調査であり、一方への答えは他方について何も語りません。
ローカルのプラットフォームインターフェースが報告できること
Android は特定のマーカーを用意しています。NetworkCapabilities オブジェクトは TRANSPORT_VPN を報告でき、hasTransport はそのトランスポートがオブジェクト上にあるかを調べます。アプリは接続性サービスからオブジェクトを取得して読み取り、ネットワーク状態の権限の範囲内で行います。
結果はローカルのプラットフォーム情報であり、プロバイダーのアドレス範囲を引く照会ではありません。呼び出したアプリが使っているネットワークを記述します。
二つの限界が重要です。アプリを除外する分割トンネルの規則があると、同じ端末でも同僚が見るのとは違う答えになり得ます。アプリが別の場所に束縛されている可能性があるからです。マーカーは OS が VPN インターフェースをモデル化しているから存在するのであり、特定のアプリが集めているからではありません。アプリがこのフィールドを読むか、転送するか、無視するかはそのアプリの性質です。そのマニフェストとドキュメントだけが、この問いに対する信頼できる情報源です。
adb shell dumpsys connectivity | grep -i -m5 vpn遠隔のサービスが見えるもの
サーバーは接続の送信元アドレス、トランスポート、タイミングを見て、アドレスを登録情報や経路情報で豊かにできます。アプリが送るものもすべて受け取れます。アプリが求め利用者が同意した場合の位置情報も含みます。これらの経路は別々であり、アドレス照会に似ているのは一つだけです。
ホスティング事業者に登録されたアドレスはトンネルを示唆し、住宅用ネットワークに登録されたアドレスは家庭の接続を示唆します。どちらも統計的な手がかりであり、端末についての事実ではありません。
住宅のアドレスはその人をその場所に置くものではなく、ホスティングのアドレスは事業者や国を名指しするものでもありません。推測を確実とみなすサービスは、検知できないまま時折誤ります。求められるのが経験則ではなく信頼性なら、アドレスのデータでは答えられません。そう明言する設計は、推測を隠す設計より誠実です。
| 証拠 | 何に答えるか | 何を示せないか |
|---|---|---|
| ローカルのトランスポートマーカー | このネットワークオブジェクトが VPN かどうか | 出口を誰が運用しているか、端末がどこにあるか |
| 遠隔の送信元アドレス | どのアドレスがサービスに届いたか | 端末がトンネルも持っているか |
| アプリケーションのペイロード | アプリが何を送ると選んだか | アプリが送らなかったすべて |
自己ホストの出口が片側だけを変える理由
自分のエンドポイントを動かすと、遠隔のサービスが見る送信元アドレスが変わり、そのサービスが商用事業者と結びつける範囲の外に出ることがあります。ローカルのネットワークモデルでは何も変わりません。トンネルはトンネルのままであり、OS は今もそれを報告するからです。
証拠の片側は動き、もう片側は固定されたままです。その隙間が期待の崩れる場所です。
ブラウザーは独自のインターフェースと制約を持つ第三の事例です。ウェブのコンテンツはネイティブの機能オブジェクトを読めず、モバイル OS の機能をウェブページが使えるものとして扱うのはカテゴリーの誤りです。問いがウェブサイトに関わるなら、プラットフォーム API を書き写すのではなく、ウェブサイトが実際に何を得られるかを調べてください。
立てた問いで決める
特定のアプリがトンネルの状態を観測できるかという問いなら、プラットフォームのインターフェースが正しい見る場所であり、答えはそのアプリのコードと権限にあります。サービスが何を推測できるかという問いなら、接続のメタデータが証拠です。法的または契約上の問いはどちらでも決まりません。
何かを集める前に、問いを一文で名づけてください。その一文が、どの観測点が重要かを決め、調査が別の議論へ流れるのを防ぎます。
報告するときは各観測にその出所の印を付けてください。印のない主張は再検討できないからです。ローカルのマーカーとアドレスからの推測はどちらも有用で、どちらも決定的ではありません。だから一つにまとめてしまうのは誤りです。
サービスが正当な接続を拒否したときは、信号を隠すためにローカルの設定を変えるのではなく、そのサービスが示す再審査の経路を使ってください。一つの観測を取り除いても、他の観測が消えたことの証明にはなりません。