SSH 터널링을 위한 공유 포트를 갖고 클라이언트를 기반으로 세션을 격리하는 것이 가능합니까?

SSH 터널링을 위한 공유 포트를 갖고 클라이언트를 기반으로 세션을 격리하는 것이 가능합니까? 예를 들어, 다음과 같이 공유 서버의 포트 9999에 대한 터널을 다른 서버에 대한 SSH 터널로 사용하는 client1이 있는 경우:

클라이언트1 포트 8888 —> 공유 호스트 포트 9999 —> 서버1 포트 4477

공유 서버의 포트 9999를 다른 클라이언트가 아래와 같이 다른 최종 호스트로 터널링하는 데 사용하도록 하는 방법이 있습니까?

클라이언트2 포트 8888 -> 공유 호스트 포트 9999 -> 서버2 포트 5568

중요한 점은 공유 호스트 포트로 전달되는 클라이언트의 로컬 포트가 항상 동일한 포트라는 것입니다. 터널은 공유 호스트에서 원하는 끝점까지 확장될 수 있지만 터널은 여전히 ​​공유 호스트의 동일한 포트를 통과합니다.

많은 것을 시도했지만 결국 해당 포트에서 client2 세션이 거부되거나 client1의 트래픽이 client2로 라우팅됩니다.

나는 이것이 이상적인 설정이 아니라는 것을 알고 있지만 불행히도 이것이 내가 처리해야 할 것입니다.

--edit-- 추가된 예:

공유 호스팅을 통해서만 액세스할 수 있는 웹 서버가 2개 있습니다. 이 예에서는 단순히 "Server 1 Response" 또는 "Server 2 Response"로 응답합니다. 인증은 rsa 키로 처리되며 user1과 user2는 완전히 별도의 하드웨어를 사용합니다.

user1이 먼저 연결합니다.

user1@localbox1$ ssh -t -L 8888:localhost:9999 [email protected] "ssh -L 9999:localhost:80 [email protected]"
[email protected] $ 

터널은 예상대로 작동합니다.

user1@localbox1$ curl "http://localhost:8888"
server1 repsonse
user1@localbox1$

사용자 2가 연결을 시도하면 오류 메시지가 표시되고 사용자 1의 터널을 사용합니다.

user2@localbox2$ ssh -t -L 8888:localhost:9999 [email protected] "ssh -L 9999:localhost:80 [email protected]"
bind: Address already in use
channel_setup_fwd_listener_tcpip: cannot listen to port: 9999
Could not request local forwarding.
[email protected] $ 

그러면 User1의 세션이 User2의 터널로 전달됩니다.

user2@localbox2$ curl "http://localhost:8888"
server1 response
user2@localbox2$

터널이 이미 생성된 경우 응답은 가 server2 response아닙니다 server1 response.

아쉽게도 최종 호스트 주소가 변경될 수 있고 이러한 값을 사용자 측에서 확인할 수 없기 때문에 두 번째 터널에 대한 원격 명령이 필요하다는 점은 주목할 가치가 있습니다. 단순화를 위해 이 예에서는 실제 최종 호스트 주소를 사용했습니다.