socat SOCKS 브리지: 사이트의 TLS 호스트 이름 유지

하나의 SOCKS 대상에 루프백 TCP 수신기를 사용하면서 애플리케이션에서 HTTP와 TLS 정체성을 유지합니다.

애플리케이션에는 SOCKS 옵션이 없지만 선택한 TCP 주소로 연결할 수 있습니다. 고정 대상 어댑터는 한 대상에 대한 SOCKS 대화를 제공할 수 있습니다. 또 하나의 범용 포워드 프록시가 될 필요는 없습니다.

SOCKS4A를 제공하는 socat 빌드에는 다음과 같은 예시 구성이 있습니다.

socat TCP4-LISTEN:9443,bind=127.0.0.1,reuseaddr,fork \
  SOCKS4A:127.0.0.1:service.example.net:443,socksport=1080

SOCKS 엔드포인트는 로컬 포트 1080입니다. 어댑터는 로컬 포트 9443에서 수신하고 그 엔드포인트에 service.example.net:443를 요청합니다. 이는 예시 값이며 완전한 서비스 배포가 아닙니다.

어댑터에는 하나의 고정 대상이 있습니다

수락된 각 TCP 연결은 같은 서비스를 요청합니다. 9443에 연결하는 애플리케이션은 평소의 프로토콜 바이트를 보내고, socat이 SOCKS4A 협상을 제공합니다. 9443으로 새 HTTP CONNECT 요청을 보내도 다른 대상을 선택하지 않으며, 그 바이트를 고정 서비스로 전달할 뿐입니다.

SOCKS4A는 원격 해석을 위해 SOCKS 엔드포인트에 호스트 이름을 제공합니다. 이는 클라이언트가 선택한 주소를 쓰는 SOCKS4 형식과 다릅니다. 선택한 업스트림은—SOCKS4 프록시 목록의 공개 후보를 포함해—SOCKS4A 호스트 이름 처리와 필요한 인증을 지원해야 합니다. 이 예시는 SOCKS5 비밀번호 로그인 절차가 아닙니다.

로컬로 연결하고 실제 서비스를 식별하십시오

HTTPS URL을 https://127.0.0.1:9443/로 바꾸면 클라이언트가 TLS와 HTTP에 사용할 수 있는 호스트 이름이 바뀝니다. service.example.net용 인증서가 루프백용 유효 인증서가 되지는 않습니다.

클라이언트가 별도의 연결 라우팅을 지원하는 경우 원래 URL의 정체성을 유지하십시오. Curl은 그 차이를 보여 줄 수 있습니다.

curl --noproxy '*' \
  --connect-to service.example.net:443:127.0.0.1:9443 \
  https://service.example.net/

소켓은 로컬 어댑터로 가고 TLS 검증과 HTTP 대상은 service.example.net으로 남습니다. 다른 애플리케이션에는 각자의 동등한 지원 제어가 필요하며, 모든 클라이언트가 그것을 제공하지는 않습니다.

루프백 바인딩은 네트워크 노출을 제한하지만 다른 적격 로컬 프로세스는 여전히 접근할 수 있습니다. 서비스 수명과 사용자를 적절히 유지하십시오. 루프백 URL 때문에 생기는 정체성 오류를 억제하지 말고 TLS 검증을 유지하십시오.

관련 글