透過プロキシの DNAT：戻り経路が重要な理由
DNAT がリクエストを別のプロキシに届けても、応答がゲートウェイを迂回して接続が切れる理由を理解します。
リダイレクトされた SYN が Squid に届いても、クライアントはまだタイムアウトします。DNAT 構成では、戻りのパケットも変換状態を持つゲートウェイに届く必要があります。
この仮想の LAN を考えてみます。
client 192.168.40.25 → gateway 192.168.40.1
DNAT → proxy 192.168.40.10
proxy 192.168.40.10 → client 192.168.40.25 directlyクライアントは当初ウェブサイトのアドレスに接続しました。DNAT 後、プロキシはクライアントの送信元を認識し、ローカルサブネットの経路を使って直接応答することがあります。その応答はゲートウェイの逆変換を通らず、期待したウェブサイトのアドレスではなくプロキシのアドレスからクライアントに届きます。ゲートウェイは受け取っていないパケットを修復できません。
| 方法 | 結果 |
|---|---|
| プロキシの応答を変換を行うゲートウェイ経由で通す | プロキシへの着信接続はクライアントの送信元アドレスを保てる |
| 適切な送信元変換も適用する | プロキシはゲートウェイを相手として応答するが、元のクライアントではなく変換された送信元を見る |
ログを見やすくするために、戻り経路を確認せずに SNAT を外さないでください。広く適用すると送信元 ACL と帰属も変わります。その結果を設計の一部として受け入れてください。
信頼できる HTTP ホップは転送ヘッダーでクライアントのメタデータを伝えられますが、NAT はそのヘッダーを作らず、TCP ピアの同一性にも変えません。Squid への接続で送信元を保つことは、Squid の別のウェブサイト接続でも保つことにはなりません。
最後に、インターセプトの設計は依然として Squid が必要とする宛先情報 を提供しなければなりません。対称的な戻り経路はこのタイムアウトの仕組みを解決するのであって、透過プロキシ構成の全体を解決するわけではありません。