SOCKS5에서는 클라이언트가 목적지 요청을 보내기 전에 인증이 협상됩니다. 그래서 초기의 자격 증명 실패는 프록시 너머의 FTP, HTTPS 또는 다른 애플리케이션 실패와 다른 사건입니다.

클라이언트의 인사말에는 지원하는 인증 방법이 나열됩니다. 서버는 그 목록에서 한 가지 방법을 선택해 선택 결과를 돌려보냅니다. 0xff 값은 제시된 어떤 방법도 받아들일 수 없으며 연결을 닫아야 함을 뜻합니다. 비밀번호가 실패한 뒤에 클라이언트가 서버 측의 모든 방법을 그냥 시도하는 것은 아닙니다.

Dante의 순서가 제어하는 것

Dante 1.4.x는 프로토콜 수준 설정을 socksmethod이라고 부릅니다. 문서에 따르면 방법은 우선순위 순서로 나열됩니다. 두 방법을 모두 허용하는 정책에서 이 선언은 클라이언트가 제시할 때 사용자 이름/비밀번호를 선호합니다:

socksmethod: username none

목록을 뒤집으면 두 방법이 모두 제시될 때 인증 없는 접근을 선호합니다:

socksmethod: none username

이것들은 대체 방법 선언이며 완전한 서버 구성이 아닙니다. 수신 인터페이스, 허용된 클라이언트, 목적지 규칙, 규칙별 인증 제약은 여전히 중요합니다.

none을 허용하면 구체적인 결과가 있습니다. 인증 없음만 제시하는 클라이언트가 적용되는 규칙 아래에서 받아들여질 수 있습니다. username을 맨 앞에 두어도 none이 포함된 목록이 모든 사람이 비밀번호를 제공해야 하는 요구 사항이 되지는 않습니다.

먼저 요구 사항을 고르세요

허용된 모든 클라이언트가 사용자 이름/비밀번호로 인증해야 한다면, none을 일반적인 호환성 수정으로 추가하는 대신 그 요구 사항을 전역 규칙과 적용되는 규칙에 일관되게 구성하세요. 제한된 클라이언트 그룹에 익명 접근이 의도된 것이라면 그 그룹과 허용된 목적지를 명시하세요.

Dante에는 clientmethod도 있는데, 이는 TCP 클라이언트가 연결할 때 SOCKS 협상 전에 수행되는 검사에 관한 것입니다. SOCKS5 인사말에서 교환되는 방법과는 별개의 계층입니다. 더 오래된 method 키워드를 사용하는 구성 조각은 설치된 Dante 버전의 설명서에 비추어 읽어야 합니다.

두 클라이언트가 다르게 동작할 때는 각자가 무엇을 제시하는지, Dante가 무엇을 선택하는지, 선택된 방법의 하위 협상이 성공하는지 비교하세요. 그다음 SOCKS 목적지 응답을 살펴보세요. 이 순서는 모든 실패를 FTP 탓으로 돌리거나 서버의 인증 정책을 무작정 바꾸지 않고도 빠진 자격 증명 콜백을 식별합니다.

마지막으로 SOCKS5 사용자 이름/비밀번호 인증은 비밀번호 교환을 암호화하지 않습니다. 그 자격 증명에 기밀성이 필요할 때는 적절히 보호된 전송 또는 네트워크를 사용하세요.

관련 글