アプリがインターフェースに束縛されている？ VPNの経路は既定ではない

同じマシン上の一方のアプリはVPNから出て、他方は出ない。どちらの利用者も何も変えていないと断言する。違いは多くの場合、アプリ自身が下す束縛の判断にある。デバイスに結び付いたソケット、接続前に選んだ送信元アドレス、独自の経路表を持つ名前空間である。いずれも適用される経路を変え、どれもブラウザの一般的なIP確認には現れない。

三つの異なる束縛、三つの異なる影響

デバイスへの束縛と送信元アドレスへの束縛は関連する操作だが、結果は異なる。デバイス束縛は通信を一つのインターフェースから出るよう強制し、そのソケットの通常の経路検索を迂回させうる。送信元アドレスの束縛は今も経路選択を通るが、選ばれた送信元がポリシーの規則に一致し、パケットを別の場所へ送ることがある。この区別は、規則が送信元で経路を決めるまでは学問的に聞こえる。そのときにはすべてを決めている。

ネットワーク名前空間は第三の事例である。独自のインターフェースと経路表を持つため、その中のアプリはホストの既定の影響をまったく受けない。三つを同じものとして扱うと、最初の試験に耐えない自信過剰な説明が生まれる。

アプリが実際に設定するものを見極める

経路に触れる前に、アプリのネットワーク設定か文書化された動作を読む。インターフェースの選択、送信元アドレスの欄、名前空間のオプションがあれば、その設定が最初に調べるべきものだ。なければ束縛は内部にあり、追跡か独自の診断でしか見えないかもしれない。

LinuxではSO_BINDTODEVICEのようなソケットオプションに文書化された範囲と権限の要件があり、特権のないプロセスは設定すらできないことがある。この制約は有用な手掛かりだ。オプションを適用できなければ、アプリは違いの原因ではない可能性が高い。

ポリシー経路は送信元を読む

ポリシー経路が設定されていると、規則はパケットの送信元に基づいて表を選べる。そのため送信元アドレスを束縛したソケットは、既定の経路が決して触れない規則に従うことがある。インターフェースが明示されていなくても同じだ。

アプリが使うのと同じアドレスファミリー、送信元、名前空間で検索を再現する。ホストの名前空間のシェルからの一般的な経路検索は別の問いに答えており、この不一致が、機能する経路を壊れて見せる最も一般的な理由である。

分割トンネルと補助プロセス

アプリごとの分割トンネルはさらに層を増やす。クライアントはアプリのパッケージやプロセスに一致させることがあり、独自のソケットを開く補助者は別の主体である。ランチャーとそのバックグラウンドサービスは、同じ見える名前の下で異なる接続を生みうる。

分割トンネルの規則が実際に接続するプロセスを覆っているか確認する。アプリが特定のインターフェースに束縛され、VPNクライアントがパッケージで一致させる場合、どちらも誤りでないまま二つの判断が食い違うことがある。

アプリ自身の経路を試験する

変更のたびにアプリから新しい要求を実行する。望んだ出口を示すブラウザは、別のインターフェースに束縛された別のプログラムにとって同等の証拠ではない。またキャッシュされた接続は、設定を変えた後も長く古い経路を使い続けることがある。新しい規則を判断する前に古いセッションを閉じる。そうしなければ試験は過去を測っている。

LinuxのソケットリファレンスはSO_BINDTODEVICEとその要件を文書化している。まずアプリ自身の設定を読み、同じ文脈で検索を再現し、そのうえで経路と束縛のどちらを変えるべきか決める。