투명한 TCP-SOCKS 전달에서 원래 목적지

방화벽은 TCP 연결이 어디로 도착하는지를 바꿀 수 있습니다. 하지만 그 변경만으로는 원래 애플리케이션에 SOCKS를 말하도록 가르칠 수 없습니다.

일반적인 SOCKS 서버는 요청된 목적지를 기술하는 협상을 기대합니다. 프록시를 모르는 애플리케이션은 대신 자신의 프로토콜 바이트를 즉시 보냅니다. 그 바이트를 곧바로 SOCKS 리스너로 보내면 양쪽은 첫 메시지에 대해 서로 다른 생각을 갖게 됩니다.

빠진 구성 요소는 변환기입니다

투명한 TCP-프록시 구성 요소는 그 인터페이스들 사이에 위치합니다. 애플리케이션이 처음 요청한 목적지를 알아내고, 적절한 SOCKS 또는 HTTP CONNECT 세션을 수립한 뒤, 그렇게 만들어진 스트림 위로 애플리케이션 데이터를 중계합니다.

Linux iptables 경로에서는 redsocks 소스가 보존된 목적지를 SO_ORIGINAL_DST 를 통해 가져옵니다. 다른 운영 체제와 리디렉션 방식은 다른 메커니즘을 사용합니다. 이는 리디렉터와 네트워크 구성의 속성이지, 일반적인 SOCKS 클라이언트의 기능이 아닙니다.

원래 목적지 정보는 리디렉션 규칙을 프록시 호스트에서 무관한 게이트웨이로 옮기는 것이 왜 항상 동등하지 않은지도 설명합니다. 수신 프로세스는 자신의 가로채기 방식이 요구하는 메타데이터를 필요로 합니다. 다른 곳에서 다시 쓰인 주소는 더 이상 그 정보를 기대하는 형태로 제공하지 못할 수 있습니다.

변환기의 범위를 분명히 하십시오. 동작하는 리디렉션된 TCP 연결은 임의의 UDP, ICMP 또는 모든 리졸버 경로에 대한 지원을 입증하지 않습니다. 상위 프록시 프로토콜과 변환기의 구현이 지원되는 작업을 여전히 규정합니다.

연결 직후에 구성이 실패하면 접근 규칙을 넓히기 전에 프로토콜 경계를 점검하십시오. 완벽하게 도달 가능한 SOCKS 리스너도 한 번도 SOCKS 요청이 아니었던 바이트를 거부할 수 있습니다.