ホットスポットのクライアントにとって分割トンネルはアプリ単位の除外ではない
アプリを VPN から除外しても変わるのはスマートフォンだけです。テザリングされたノート PC には、送信元・宛先・NAT で照合する独自の転送ルールが必要です。
同じに聞こえる二つの要件、「このアプリを VPN から除外する」と「この一つの宛先を、私のホットスポット上のノート PC のために VPN の外へ送る」は同じではありません。前者はスマートフォンのソケットがどのネットワークを選ぶかを変えます。後者は、スマートフォンがすでに受け入れた後で別の機器から届いたパケットの転送判断を変えなければなりません。この二つを混同すると、ホットスポットのクライアントには、常にスマートフォン自身のブラウザーにしか当てはまらない例外が残ります。
二つの問いを所有する二つのサブシステム
Android はアプリのネットワークとテザリングを別々に保ちます。アプリのソケットは接続スタックによってネットワークに割り当てられ、VPN アプリが自分のソケットのどれをトンネルに入れるかを決めます。テザリングされたクライアントから転送されるパケットはテザリングのサブシステムが扱い、下流のインターフェースで経路、ポリシールール、変換を netd に問い合わせます。
アプリ単位の除外は、アプリがソケットを開くときに評価されます。転送されたパケットは、このデバイスのアプリのソケットから生じたものではないため、その検査に決して到達しません。二つの設定が互いに代用できない理由はまさにこれであり、どちらの不具合でもありません。
アプリ単位の除外が実際に変えるもの
VpnService のビルダーは addDisallowedApplication でトンネルの外に残すパッケージを指定でき、addAllowedApplication で内部で許可する唯一のパッケージを指定できます。それらのアプリは基盤のネットワークでソケットを開き、VPN はそれ以外すべての既定経路を引き続き所有します。
範囲は正確で、そのパッケージ自身のソケットが、このデバイス上で、トンネルが上がっている間だけです。転送される通信については何も述べておらず、二台目の機器についても、システムがテザリングの代理で送るパケットについても何も述べていません。
宛先の制御でもありません。ブラウザーを除外すると、そのブラウザーが到達するすべてのアドレスが除外され、トンネル内に残したかったものも含まれます。要件が アプリではなく宛先 を指定するとき、アプリの選択は構造上すでに誤った道具です。
テザリングされたパケットがスマートフォンからどう見えるか
クライアントのパケットは、スマートフォンが割り当てたプライベートな送信元アドレス、たとえば 192.168.43.20 と、公開の宛先を伴ってホットスポットのインターフェースに届きます。転送には、クライアントのプライベートアドレスがセルラーネットワークでは意味を持たないため、応答が戻る道を見つけられるように上流への経路と変換ルールが必要です。
Android はこれをルーティングテーブルを選ぶポリシールールで表現し、ネットワークや VPN が変わると netd が該当するテーブルとルールを再構築します。フォーラムの投稿や同じモデルの古いリリースからコピーしたテーブル番号、ルールの優先度、インターフェース名は、恒久的な所有を確立しません。この再構築こそ、手書きのルールがある一時間は動いて次の再接続で止まりうる理由です。
ホットスポットの例外に本当に必要なポリシー
ルールに触れる前に判断を送信元・宛先・意図する経路として書き出し、承認された一つの宛先の最小の形は次のとおりです。
| Source | Destination | Intended path |
|---|---|---|
| One authorized hotspot client | One approved public service address | Ordinary cellular uplink |
| The same client | All other covered destinations | Shared VPN |
| The phone's own apps | Their existing destinations | Unchanged phone policy |
両方向が完全でなければなりません。直接の枝には、たまたま現在のセルラー上流を通る使用可能な経路が必要で、VPN の枝には、トンネルの経路と転送の許可が必要です。送信元の変換は、トンネルのインターフェースに適用された NAT がトンネルのアドレスを示してセルラーのアドレスではないため、選んだ出口に一致しなければなりません。
応答は追跡された状態か明示的な経路によって同じ下流のクライアントに届かなければならず、外向きパケットのカウンターはそのどれも証明しません。VPN 自身の外側の転送も例外の範囲の外に置かないと、トンネルの搬送パケットがクライアントのウェブ要求のために書かれたポリシーを継承します。
一つの捕捉されたアドレスは宛先ではない
ブラウザーから読み取った一つの IPv4 アドレスは一枚のスナップショットです。大規模なサービスは anycast や回転するエッジアドレスの集合から応答し、多くはデュアルスタックで、ログインの流れはページが決して表示しない認証やテレメトリーのホストに触れることがあります。たまたま見たアドレスの周りに作った例外は、次にサービスが負荷を再配分したときに壊れます。
サービスの所有者が文書化したアドレス、または公開している範囲を使い、両方のアドレスファミリーを考慮してください。要件を安定した集合として表現できないなら、それはおそらくサービス側のポリシーの問題であり、スマートフォンでのルーティングの小技ではありません。
下流側から検証する
この順で、ノート PC から選んだサービス、VPN の内側に残らなければならない普通の宛先、影響を受けてはならないスマートフォンのアプリの三つを確認します。そのあと、ポリシーのテーブルが再構築される再接続の後と上流の変更の後にもう一度行ってください。
スマートフォンの共有の実装が再接続をまたいでその契約を保てないなら、端末に root のルールを積み上げるのではなく、選択的なポリシーを対応する下流のルーターへ移してください。ルーターは安定した所有者とともに送信元と宛先の照合を表現でき、テザリングモジュールのドキュメントが、スマートフォンが実際に何をしているかの正しい参照先です。