Squid 상위 프록시에 별도 자격 증명 설정하기

사용자가 Squid 서비스에 로그인할 때와 Squid가 상위 프록시에 로그인할 때의 자격 증명은 다릅니다. 상위 프록시는 다른 운영자 소유이거나 다른 계정 데이터베이스를 사용할 수 있습니다. 클라이언트 비밀번호를 받아들였다고 해서 상위로 전달해야 한다고 가정하지 마세요.

Squid 6.13은 상위 프록시 정의에 고정 로그인 정보를 붙일 수 있습니다.

cache_peer 192.0.2.20 parent 3128 0 no-query default name=upstream login=parentuser:ExampleOnly

위 주소와 비밀번호는 문서용 예시입니다. 실수로 두 번째 피어를 만들지 말고 기존 상위 프록시 정의에 로그인 정보를 적용하세요. 어떤 요청이 이 상위 프록시를 반드시 사용할지 결정하는 별도의 라우팅 정책도 유지하세요.

계정 범위를 구분하세요

하위의 auth_param 설정은 해당 Squid 인스턴스의 클라이언트를 검증합니다. 피어의 login 옵션은 다른 홉의 자격 증명을 제공합니다. 한쪽을 바꿔도 다른 쪽은 자동 갱신되지 않습니다.

상위 프록시 문서의 인증 요구 사항에 맞추세요. 이 한 줄은 모든 연결 지향 인증 방식의 완전한 설정이 아닙니다. 상위가 NTLM 또는 Negotiate를 요구하면 이 필드의 비밀번호를 반복해서 바꾸기보다 지원되는 피어 구성을 확인하세요.

Squid에는 PASS, PASSTHRU 같은 자격 증명 전달 옵션도 있습니다. 전용 상위 계정과 의미가 다르며 클라이언트 인증 정보를 피어에 노출할 수 있습니다. 별도 계정을 쓰는 설계라면 지름길로 선택하지 마세요.

설정을 보호하고 올바른 홉을 시험하세요

고정 비밀은 설정에 저장됩니다. 파일과 백업 접근을 제한하고 파서나 디버그 출력을 공유하기 전에 민감한 정보를 제거하세요. 이 옵션에는 자체 이스케이프 규칙이 있습니다. 문서는 URL 이스케이프를 허용하며 리터럴 퍼센트 문자는 두 번 쓰도록 요구합니다.

클라이언트 인증은 성공하지만 전달 요청이 상위에서 계속 실패하면 그 상위 교환과 계정을 살펴보세요. 클라이언트–Squid와 Squid–상위 프록시의 전송 보호도 구분하세요. 첫 연결을 암호화해도 두 번째 연결은 자동으로 보호되지 않습니다.