Squid의 allow 규칙 하나는 AND, 둘은 OR일 수 있다

이 정책을 소리 내어 읽어 보자. 사무실 네트워크가 승인된 목적지에 프록시를 사용하도록 허용한다. 이 조건들이 함께라면 규칙에서도 함께 유지한다.

http_access allow office_clients approved_destination

그 줄이 요청을 허용하려면 두 ACL이 모두 일치해야 한다. 줄을 나누면 정책이 바뀐다.

http_access allow office_clients
http_access allow approved_destination

이제 사무실 클라이언트는 목적지 제한 없이 허용될 수 있고, 그 목적지로의 요청은 사무실 제한 없이 허용될 수 있다. 단, 앞선 규칙이 이를 거부하지 않았다면 그렇다. 두 줄은 한 줄의 더 읽기 쉬운 표기가 아니다.

순서도 정책의 일부

Squid는 접근 규칙을 순서대로 평가한다. 처음 일치하는 결정이 요청을 제어한다. 앞선 allow all는 뒤의 신중한 제한을 무력화하고, 앞선 일치 거부는 뒤의 허용에 도달하지 못하게 한다.

http_access 문서가 이 순서를 설명한다. 독자가 암묵적 기본 동작을 기억한다고 믿는 대신 의도적인 마지막 거부를 남겨 두자.

많은 ACL 정의는 다른 OR 관계를 가진다. 이름이 붙은 원본 ACL 하나가 여러 허용 범위를 나열할 수 있다. 그렇다고 원본과 목적지의 정체성이 같은 ACL 유형이 되지는 않는다. 둘을 따로 정의한 뒤 접근 결정에서 이름을 결합하자.

사설 출구에서는 누가 외부 IP를 쓸 수 있는지에 영향을 준다. 네 가지 경우를 생각해 보자. 승인된 클라이언트에서 승인된 목적지, 승인된 클라이언트에서 다른 곳, 다른 클라이언트에서 승인된 목적지, 다른 클라이언트에서 다른 곳. 만약 규칙이 정책이 의도한 것보다 많은 경우를 허용한다면 리스너를 넓히기 전에 논리를 고치자. 문법적으로 유효한 설정도 잘못된 권한을 표현할 수 있다.