프록시가 모두에게 열려 있지 않은지 확인하기
포워드 프록시를 노출하기 전에 허용·거부 출발지에서 리스너, 규칙 순서, 자격 증명과 실제 전달을 검증합니다.
새 포워드 프록시를 다른 네트워크에서 접근 가능하게 하기 전에 접근 경계를 시험하세요. 서버 자체의 요청 성공만으로는 무관한 클라이언트가 무엇을 할 수 있는지 거의 알 수 없습니다. 거부된 요청이 실제로 전달됐는지 판단하도록 통제 가능한 목적지를 사용하세요.
실제 리스너와 정책 확인하기
수신 대기 프로세스와 주소를 확인하고 IPv6가 켜져 있으면 포함하세요. 의도치 않은 추가 리스너나 오래된 서비스 인스턴스를 제거하세요. 네트워크 방화벽은 서비스에 도달해야 하는 출발지로 제한하세요.
다음으로 포함 파일을 포함해 프로세스가 실제로 읽은 설정을 보세요. Squid 6에서는 앞의 허용이 뒤의 제한을 무의미하게 만들 수 있습니다. Tinyproxy 1.11.2에서는 모든 Allow와 Deny 줄을 지우면 모든 클라이언트가 허용됩니다. Dante는 클라이언트 규칙과 SOCKS 규칙이 별개이므로 TCP 연결 허용만으로 전체 정책이 되지는 않습니다.
설치된 버전의 문서를 사용하세요. Squid 8의 지시문 변경은 버전을 확인해야 하는 이유이지, 익숙한 설정이 같은 의미로 받아들여졌다고 가정할 이유가 아닙니다.
허용·거부 사례 모두 테스트하기
승인된 출발지와 로그인을 모두 요구하려는 프록시라면 통제하는 시스템에서 다음 조합을 시험하세요.
| 출발지 | 자격 증명 | 필수 결과 |
|---|---|---|
| 허용됨 | 유효함 | 의도한 목적지가 요청을 받는다. |
| 허용됨 | 없거나 틀림 | 목적지에 도달하지 않는다. |
| 허용 안 됨 | 유효하거나 없음 | 목적지에 도달하지 않는다. |
하나의 NAT 뒤 두 기기는 같은 출발지로 보일 수 있습니다. 프록시에서 출발지 주소가 다른 테스트 위치를 고르고 로그에서 확인하세요. 무관한 제삼자 기기를 쓰거나 다른 사람의 서비스를 스캔하지 마세요.
방화벽 거부에는 HTTP 응답이 전혀 없을 수 있고 앱 거부에는 오류가 반환될 수 있습니다. 두 경우 모두 통제하는 목적지가 금지된 요청을 받지 않았는지 확인하세요. 오류 페이지만 보면 목적지 응답과 혼동할 수 있습니다.
허용할 전달 방식 시험하기
웹 프록시는 일반 HTTP 요청과 허용된 HTTPS CONNECT 경로를 따로 시험하세요. 목적지 제한이 정책에 포함되면 허용 목적지와 거부돼야 할 통제 가능한 목적지를 시험하세요. 테스트를 모두 성공시키려고 통제를 제거하지 마세요.
출발지 범위, 자격 증명, 리스너 주소, 포함 파일이나 서비스 버전이 바뀌면 다시 시험하세요. 테스트 시간, 설정 버전과 결과를 함께 보관해 이후 변경도 같은 경계와 비교하세요.
이는 인수 절차이며, 설정 파서나 요청 한 번으로 모든 네트워크 경로가 닫혔다고 입증할 수 있다는 주장이 아닙니다.