올바른 비밀번호는 이 정책의 절반일 뿐입니다. 계정은 승인된 클라이언트 주소에서도 작동해야 합니다. Squid에서는 두 검사를 동일한 액세스 규칙에 두는 것이 그 요구 사항과 두 개의 별도 진입 경로 사이의 차이입니다.

인증이 이미 구성되어 있다고 가정하면, 예를 들어 Squid 6.13 NCSA 설정과 같으면 핵심 정책은 다음과 같습니다.

acl approved_login proxy_auth alex
acl approved_source src 192.0.2.40/32
http_access allow approved_source approved_login
http_access deny all

Squid가 실제로 수신하는 소스를 사용하세요. 샘플은 문서용 주소입니다. 안전하지 않은 대상 포트, 로컬 서비스, CONNECT 트래픽에 대한 이전 보호를 유지하세요. 이 조각은 결합된 조건을 보여 주며 전체 리스너 구성은 아닙니다.

그 위의 규칙을 확인하세요

이전의 광범위한 허용은 새 조건에 도달하기 전에 요청을 수락할 수 있습니다. http_access 참조는 순서대로 일치하는 방식을 설명합니다. 포함된 파일을 포함하여 전체 순서를 읽으세요.

사용자 이름에 대한 허용과 소스에 대한 허용은 둘 다를 요구하지 않습니다. 어느 줄이든 독립적으로 성공할 수 있습니다. 그것은 다른 정책입니다.

proxy_auth ACL은 인증 도우미에 의존합니다. 이를 정의하는 것은 사용자를 생성하거나 비밀번호를 검증하는 방법이 아닙니다. 이 예제는 클라이언트가 프록시 인증 챌린지에 응답할 수 있는 명시적 프록시를 위한 것입니다.

소스 ID에도 한계가 있습니다. 하나의 NAT 뒤에 있는 사람들은 주소를 공유할 수 있고, 이동하는 노트북은 주소를 바꿀 수 있습니다. 추가 조건은 계정의 사용 가능한 네트워크 위치를 좁힐 뿐 실제 컴퓨터를 안정적으로 식별하지는 않습니다. 이 제한이 조건을 처음 추가한 이유와 일치하는지 확인하세요.

관련 글