Squid の allow ルール 1 本は AND、2 本は OR になり得る

このポリシーを声に出して読んでみよう。オフィスのネットワークに、承認済みの宛先へプロキシを使うことを許可する。これらの条件が一体なら、ルールの中でも一体に保つ。

http_access allow office_clients approved_destination

その行でリクエストを許可するには、両方の ACL が一致しなければならない。分割するとポリシーが変わる。

http_access allow office_clients
http_access allow approved_destination

これでオフィスのクライアントは宛先の制限なしに許可され、その宛先へのリクエストはオフィスの制限なしに許可される。ただし、それより前のルールが拒否していれば別だ。2 行は 1 行の読みやすい書き方ではない。

順序もポリシーの一部

Squid はアクセスルールを順番に評価する。最初に一致した判断がリクエストを制御する。前にある allow all は、後にある慎重な制限を無効にする。前にある一致する拒否は、後の許可に到達するのを妨げる。

http_access のドキュメント がこの順序を説明している。暗黙の既定動作を読者が覚えていることに頼らず、意図的な最後の拒否を残す。

多くの ACL 定義は別の OR 関係を持つ。名前付きの送信元 ACL 1 つが複数の許可範囲を列挙できる。だからといって送信元と宛先の同一性が同じ ACL 型になるわけではない。別々に定義し、アクセス判断で名前を組み合わせる。

プライベートな出口では、誰が外向き IP を使えるかに影響する。4 つのケースを考えよう。承認済みクライアントから承認済み宛先、承認済みクライアントから他の場所、別のクライアントから承認済み宛先、別のクライアントから他の場所。もし ルールがポリシーの意図より多くのケースを許可している なら、リスナーを広げる前にロジックを直す。構文的に正しい設定でも、誤った権限を表すことがある。