Squid のリスナーポートを送信元 IP に対応付ける

プロキシポートが 4 つあるからといって、自動的にパブリック IP が 4 つあるわけではありません。Squid は通常、外向き接続の送信元アドレスをオペレーティングシステムに選ばせます。ポートの選択を意味のあるものにするには、明示的な送信元アドレスポリシーに結び付けます。

これらのディレクティブに対応する Squid 7 の構成では、ルーティングの断片で名前付きリスナーを使用できます。

http_port 3128 name=exit_a
http_port 3129 name=exit_b
acl on_a myportname exit_a
acl on_b myportname exit_b
tcp_outgoing_address 192.0.2.10 on_a
tcp_outgoing_address 192.0.2.11 on_b

ここに示したアドレスはドキュメント用の例です。お使いのホストで割り当てられ、使用可能なアドレスに置き換えてください。これはすでに制限されたプロキシ構成にルーティングを追加するものであり、認証やクライアントのアクセス規則を提供するものではありません。

送信元の選択は経路の一部にすぎません

送信元アドレスのリファレンスには、順序付きの照合とアドレスファミリーの選択が説明されています。IPv4 の送信元が IPv6 接続の送信元になることはできません。アドレスごとに異なるプロバイダーを使う場合、ホストのルーティングポリシーはそれぞれに適合するゲートウェイを使う必要があります。

上流の NAT は、選択した 2 つのローカルアドレスを 1 つのパブリックアドレスに変換することがあります。そのためリスナーの対応付けはローカルで機能しても、意図したパブリックな識別にはならない可能性があります。親プロキシが最終的なウェブサイト側の出口になることもあります。

既存の接続にも注意が必要です。Squid のドキュメントは、クライアントに依存する送信規則とサーバー側の持続接続について警告しています。以前のポリシーで確立された接続を再利用すると、変更した選択が無効に見えることがあります。

ウェブサイトから見えるアドレスを、ローカルポリシーと新しい接続と併せて解釈してください。着信ポートの違いは選択の合図であり、IP アドレスの割り当て機構ではありません。