Squid의 myportname과 src를 별도 ACL로 결합하기

설정은 언뜻 보기에 그럴듯합니다:

acl team_a myportname 3128 src 198.51.100.0/24

하지만 ACL 정의에는 유형이 하나뿐입니다. 여기서 myportname이 유형이며, src라는 단어를 더해도 두 번째 검사가 시작되지 않습니다. 나머지 단어는 첫 번째 유형의 값 목록에 속합니다. 그 줄은 “이 리스너와 이 클라이언트 네트워크”를 뜻하지 않습니다.

각 조건에 이름을 붙이기

수신 소켓에는 이름을, 출발지에는 별도 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 대상, 관리 접근에 대한 기존 보호 뒤에 두세요. 발췌는 클라이언트/리스너 조건을 보여 줄 뿐 그 보호를 대체하지 않습니다.

한 http_access 줄의 조건은 AND로 결합됩니다. 허용 줄을 둘로 나누면 각 조건이 독립적으로 통과해 정책이 크게 달라집니다. 하나의 ACL 안에 여러 값을 두면 보통 그 한 번의 검사에 대한 대안이 됩니다.

출구는 따로 고르기

일치하는 리스너는 tcp_outgoing_address로도 로컬 출발지 주소를 고르는 데 쓸 수 있습니다. 그것은 라우팅 선택이지 프록시 사용 허가가 아닙니다. 출구 주소 규칙으로 거부된 요청을 http_access로 통과시킬 수는 없습니다.

여러 주소를 쓰는 설정이 업그레이드 후 동작을 멈추면 증거를 분리하세요. 구문 분석 오류는 설정 문법을, 접근 거부는 규칙 일치를, 잘못된 출구로 허용된 요청은 출구 선택이나 이후 NAT를 가리킵니다. 세 가지를 한꺼번에 바꾸면 작은 ACL 실수를 찾기가 훨씬 어려워집니다.