TPROXY パケットをソケットまで追跡する
受信ソケット、パケットマーク、ローカルポリシールートを、透過プロキシの 1 本の配送経路として確認します。
アプリケーションが何も受信していないのに TPROXY のカウンタが増えることがあります。ルールは一致したものの、ローカル配送はポリシールーティングと適合する受信ソケットに依然として依存します。
Linux の TPROXY は DNAT のように宛先を書き換えずに通信を横取りできます。そのため、非ローカルの宛先に向かうパケットは適切なローカルソケットに到達しなければなりません。
配送経路をたどる
- 通信は想定したインターフェースとアドレスファミリーで横取りホストに届きます。
- 横取りルールとパケットマークがローカル配送ポリシーを特定します。
- 一致したポリシールールが、パケットをローカルに配送するルートを選びます。
- プロキシは必要なソケットオプションを備えた対応済みの透過リスナーを使います。
カーネルの IPv4 の例は IP_TRANSPARENT へのアプリケーションの対応を前提としています。同じポートの通常のリスナーや、グローバルな非ローカルバインド設定では、その対応を裏付けられません。
| 観察 | 次の確認 |
|---|---|
| 関連する受信パケットがない | 通信経路と入力インターフェース |
| パケットは届くが横取りカウンタが動かない | アドレスファミリー、チェーン、一致条件 |
| ルールは一致するがローカル配送に失敗する | マークとポリシールートの選択 |
| ソケットは待ち受けているがアプリケーションに何も見えない | 透過ソケットの機能とリスナーの所有者 |
| 要求は始まるが以降の応答が失敗する | 確立済みソケットの一致と戻りルート |
各観察とともに、読み込んだ設定とネットワーク名前空間を記録します。後から追加したルールがマークを上書きしたり、別のルートを選んだりすることがあります。リスナーがコンテナで動いているのにホスト側で横取りする場合、ホストのローカルルートが正しくても、そのコンテナへ自動的に配送されるわけではありません。
後続のパケットを見込む
カーネルの例には、ソケットの一致と、透過ソケットに属するパケットをマークする DIVERT 経路が含まれます。これを省くと、最初の横取りが成功しても後続の通信が別の経路に残ることがあります。
アプリケーションが対応する透過モードと、アドレスファミリーごとの該当するカーネルドキュメントを使ってください。IPv4 のローカルルート用コマンドは IPv6 を設定しませんし、一方のファミリーでの対応はもう一方のソケットの挙動を裏付けません。
TPROXY は SOCKS のネゴシエーションも生成しません。透過から SOCKS への変換部品は、依然として 宛先を検出して上流とネゴシエーションする 必要があります。
REDIRECT からの移行
既存のアプリケーションが元の宛先をどう取得しているかを記録します。REDIRECT は宛先を変更し、適切な復元手段に依存します。TPROXY には独自の透過ソケットとルーティングの取り決めが必要です。アプリケーションと送信元アドレスのポリシーに応じて選びます。
横取りの方式を変える前に、カウンタを選択したルート、ソケットの機能、アプリケーションのログと突き合わせます。必要な仕組みがそろっているディストリビューションでは、配送の手順が欠けていることのほうが、カーネルの再ビルドよりも良い出発点になります。