NF getsockopt(SO_ORIGINAL_DST) 는 원래 목적지 조회를 가리킵니다. 인터셉트 구성에서 Squid는 리디렉션된 연결이 원래 어디로 향했는지 복원해야 합니다.

명시적으로 구성된 브라우저는 요청을 의도적으로 프록시로 보냅니다. Squid 리스너의 포트 옆에 intercept 가 적혀 있다는 이유만으로 그 연결에 NAT 인터셉트 이력이 생기지는 않습니다.

따라서 이 불일치는 목적지 인증서가 문제가 되기 전에 실패할 수 있습니다.

연결이 어떻게 도착했는지부터 시작하십시오

  • 애플리케이션에 프록시 주소가 구성되어 있다면, 사용해야 할 일반 포워드 프록시 리스너를 확인하십시오.
  • 게이트웨이가 원래 직접 연결이어야 할 트래픽을 리디렉션한다면, 의도한 인터셉트 리스너에 도달하는지와 지원되는 NAT 설계가 필요한 목적지 정보를 보존하는지 확인하십시오.
  • 두 모드가 모두 존재한다면, 실패하는 클라이언트가 실제로 어느 주소와 포트에 접속했는지 확인하십시오.

Squid의 http_port 문서는 차이를 분명히 합니다. 모드 플래그를 생략하면 포워드 프록시 모드가 선택되고, intercept 는 IP 계층의 NAT 인터셉트를 기대합니다.

그다음 전송 보안은 따로 다루십시오. HTTP 프록시는 CONNECT를 통한 HTTPS 를 운반할 수 있습니다. 프록시로의 TLS 연결에는 호환되는 리스너와 클라이언트 구성이 필요합니다. 목적지 트래픽 복호화는 또 다른 선택 기능입니다.

목적지 URL이 HTTPS로 시작한다는 이유만으로 인증서 생성을 켜는 오래된 “HTTPS 해결책”을 그대로 복사하지 마십시오. 먼저 클라이언트와 리스너 사이의 합의를 고치십시오. 그 후에도 실제 TLS 오류가 남는다면, 그 오류가 조사하기에 더 유용합니다.

관련 글