Squid の myportname と src を別々の ACL で組み合わせる

設定は一見もっともらしく見えます:

acl team_a myportname 3128 src 198.51.100.0/24

しかし ACL 定義の型は 1 つだけです。ここでは myportname が型であり、src という語を足しても 2 つ目の判定は始まりません。残りの語は最初の型の値リストに属します。この行は「このリスナーとこのクライアント網」を表していません。

条件ごとに名前を付ける

待ち受けソケットには名前を、送信元には別の ACL を使ってください。この抜粋はドキュメント用アドレスを使っており、配備に適したアドレスへ置き換える必要があります:

http_port 192.0.2.10:3128 name=team_a_port
acl team_a_port myportname team_a_port
acl team_a_clients src 198.51.100.0/24

http_access allow team_a_port team_a_clients
http_access deny all

許可ルールは、危険な宛先ポート、制限された CONNECT 先、管理アクセスに対する既存の保護より後に置きます。抜粋はクライアント/リスナーの条件を示すもので、それらの保護を置き換えるものではありません。

1 行の http_access にある条件は AND で結合されます。許可行を 2 行に分けると各条件が独立して通ってしまい、ポリシーが大きく変わります。1 つの ACL 内の複数の値は、通常その 1 回の判定に対する選択肢になります。

出口は別に選ぶ

一致したリスナーは tcp_outgoing_address でも ローカルの送信元アドレスを選ぶために使えます。これは経路の選択であり、プロキシを使う許可ではありません。送信元アドレスのルールで拒否された要求を http_access に通すことはできません。

複数アドレスの構成が更新後に動かなくなったら、証拠を分けてください。解析エラーは設定構文を、アクセス拒否はルールの一致を、誤った出口で許可された要求は出口の選択や後段の NAT を示します。3 つを同時に変えると、小さな ACL の誤りが格段に見つけにくくなります。