Squid の PROXY プロトコル: HTTP アクセス検査の前に送信元を信頼する

proxy_protocol_access は、メタデータを供給するリレーを信頼するために使い、許可するウェブサイトの選択には使いません。Squid 5–7 では、この検査は TCP 確立後に require-proxy-header リスナー上で一度だけ、HTTP リクエストヘッダーの処理より前に実行されます:

acl trusted_relay src 192.0.2.20/32
http_port 3128 require-proxy-header
proxy_protocol_access allow trusted_relay
proxy_protocol_access deny all

例のリレーアドレスは置き換え、このリスナーへのネットワークアクセスを制限してください。この段階で Squid は、供給されたメタデータを受け入れる前に実際の TCP ピアを検査します。受け入れた後は、主張されたクライアントアドレスを後続の ACL 検査とログに使用します。リレーが主張するクライアントアドレスに基づいて信頼すると、この順序が逆になります。

http_access は、後段のクライアント送信元と宛先の許可のために残します。メタデータを受け入れてもウェブサイトへのアクセスは認可されず、宛先ドメインの ACL では先の送信元信頼の問いに答えられません。

送信側と受信側は、対応する PROXY プロトコルのバージョンに合意する必要があります。通常の HTTP クライアントは、必須プレフィックス付きのこのリスナーを通常のプロキシエンドポイントとしては使えません。両方の形態が必要なら、同じ待ち受けアドレスとポートを複製するのではなく、意図的に別々のエンドポイントを使ってください。

信頼されたリレーは、供給するクライアント ID を通じてアドレスベースの認可に影響を与えられます。その能力は想定された中間者だけに与えてください。