.NET 소켓에는 SOCKS 핸드셰이크가 필요합니다

Socket.Connect()을 SOCKS 서버로 향하게 하면 그 서버로 TCP 연결이 열립니다. 다음 바이트는 여전히 SOCKS를 말해야 합니다. 애플리케이션 프로토콜을 즉시 보내면 서버는 다른 대화를 기다리게 됩니다.

SOCKS5에서는 연결 설정에 방식 협상, 선택된 인증 교환, 목적지를 지정하는 요청이 포함됩니다. 성공한 응답만이 애플리케이션 바이트의 경로를 엽니다. 이 단계는 RFC 1928에 정의되어 있습니다.

협상은 연결 계층에 두십시오

자체 TCP 프로토콜을 가진 애플리케이션은 설정된 스트림을 반환하는 프록시 인식 커넥터를 사용할 수 있습니다. 그러면 나머지 애플리케이션은 그 스트림을 통해 읽고 씁니다. 커넥터는 부분 읽기, 가변 길이 주소, 인증 실패, 협상을 위한 기한을 고려해야 합니다.

고정 크기 버퍼 하나를 읽고 성공을 가정하는 직접 작성한 구현은 취약합니다. TCP는 SOCKS 메시지의 경계를 보존하지 않습니다. 애플리케이션 프로토콜을 시작하기 전에 주소 유형으로 설명되는 전체 응답을 읽으십시오. .NET 7+용 CONNECT 응답 리더가 그 단계를 보여 줍니다.

유지 관리되는 라이브러리가 이미 이 연결 계층을 제공한다면 지원하는 SOCKS 버전, 인증 방식, 대상 프레임워크를 확인하십시오. 10년 된 포럼 링크는 조사의 출발점이지 현재 호환성의 증거가 아닙니다.

HTTP 클라이언트 구성은 별도의 범위를 가집니다

HTTP 클라이언트의 프록시 설정은 그 HTTP 클라이언트를 구성합니다. 프로세스의 모든 원시 소켓을 변경하지는 않습니다. Socket API는 네트워크 엔드포인트를 받아들이고 상위 수준 협상은 호출자에게 맡깁니다.

암호화된 애플리케이션 프로토콜의 경우 프록시 터널이 설정된 후에 TLS 핸드셰이크를 수행하십시오. 그 단계에서 의도한 목적지의 신원을 검증하십시오. 프록시 인증과 목적지 인증은 같은 기반 스트림을 사용하더라도 별개로 유지됩니다.