Squid の IPv4 クライアントと IPv6 宛先：別々のポリシー

IPv4 でクライアントを受け入れ、そのクライアントが要求したウェブサイトへ IPv6 で到達することは可能です。これらは別々の接続です。ウェブサイト側に関するポリシーが IPv4 クライアントを自動的に拒否すべきではありません。

宛先ファミリーの拒否と src ipv4 を組み合わせた例にある罠はこれです。送信元 ACL は誰が接続できるかを変えるのであり、どのウェブサイト接続が許可されるかだけを変えるのではありません。

意図する制限を定義する

該当する IP ACL をサポートする Squid リリースでは、宛先ファミリーのルールが dst ipv4 を使って IPv4 宛先を識別できます。そのようなルールは既存の認証と宛先権限に統合し、それらを迂回する広範な IPv6 許可を追加しないでください。

ACL リファレンスは送信元と宛先の種類を区別します。これは制限であり、自動翻訳サービスではありません。IPv4 専用のウェブサイトは、マシンが IPv4 で到達できたとしても利用できなくなることがあります。

発信 IPv6 アドレスのバインドも、強制ポリシーのすべてではありません。送信元の選択、許可される宛先ファミリー、DNS 応答、実際のネットワーク到達性がすべて寄与します。IPv4 フォールバックが許容されるかどうかを明示的に決定してください。

forwarded_for を変更してもこの問題は解決しません。これは HTTP ヘッダーに影響するものであり、プロキシの TCP 接続のアドレスファミリーには影響しません。同様に、IPv6 DNS リゾルバーは、応答するすべての名前が IPv6 宛先を持つことを保証しません。

大規模な古い設定を採用する前に、リリース固有の動作を確認してください。特に、Squid 5 から 7 では dns_v4_first はサポートされたファミリー優先スイッチではありません。正確に説明できるポリシーのほうが、無関係な IPv6 設定の寄せ集めより検証しやすいです。