원격 포트 전달을 통한 Jumphost를 통한 SSH 세션

원격 포트 전달을 통해 SSH를 통해 연결하는 데 문제가 있습니다.

시나리오는 기업 네트워크이고 내부 네트워크의 서버("소스"라고 함)는 SSH를 통해 DMZ("대상")에 있는 서버에 로그인해야 합니다. DMZ의 대상 서버는 내부 네트워크로부터의 연결을 위해 잠겨 있으므로(내부 네트워크에서도 볼 수 없음) DMZ에 점프 호스트("jumphost")가 있습니다. 점프 호스트에서 원격 포트 전달을 설정하여 이를 달성합니다.

내부 네트워크의 원본 서버에서 점프 호스트로 이 명령을 실행합니다.

origin> ssh -R *:1234:target:22 myusername@jumphost

이는 점프 호스트에서 SSH 세션을 설정하여 포트 1234(임의의 포트 번호 예)에서 수신 대기를 시작하고 해당 포트의 연결을 대상 서버 포트 22(SSH)로 전달하는 것입니다.

그런 다음 소스 서버에서 점프 호스트까지 포트 1234에서 두 번째 SSH 세션을 설정한 다음 해당 세션은 실제로 포트 22의 대상 서버에 연결됩니다. 이것이 "실제" SSH 세션이며 작업을 완료할 수 있습니다. 대상 서버에서:

origin> ssh jumphost -P 1234

구성

점프 호스트는 원격 포트 전달을 허용하도록 구성되었습니다. sshd_config에서 다음을 설정하십시오.

AllowTcpForwarding yes
GatewayPorts yes

또한 원본 서버와 점프 호스트 사이에 포트 22(원격 포트 전달을 설정하기 위한 초기 SSH 연결용)와 포트 1234(전달된 포트의 후속 SSH 연결용)에 대한 방화벽 개방이 설정됩니다. 점프 호스트와 포트 22가 열려 있는 대상 사이에도 방화벽이 있습니다.

결과

두 번째 연결(전달된 포트를 통한 연결)을 설정하면 연결이 즉시 닫힙니다("원격 호스트에 의해 연결이 닫혔습니다").

대상 서버에서 tcpdump를 실행하면 활동이 표시되지 않습니다. 즉, 연결이 차단된 것으로 나타납니다.

그러나 점프 호스트에서 대상으로 일반 SSH 세션을 성공적으로 설정할 수 있었습니다. 둘 다 포트 22의 대상에 연결되어 있지만 전달된 포트를 통해 들어오는 경우에만 연결이 닫힙니다.

더 중요한 것은 내부 네트워크의 서버로 포트 전달을 지정하면(즉, 내부 네트워크의 원본에서 DMZ의 점프 호스트로 연결한 다음 다시 내부 네트워크의 세 번째 서버로 연결) SSH는 세션이 성공적으로 빌드되었습니다.

추측과 질문

이 모든 것은 일부 네트워크 보안 설정이 작동하여 점프 서버의 전달된 포트를 통해 DMZ 내의 대상 서버에 대한 연결을 방해하고 있다고 믿게 만듭니다. 불행히도 나는 알 만큼 충분하지 않습니다:

(1) 네트워크 보안 정책 관점에서 원본 서버에서 점프 서버의 전달된 포트를 통한 SSH 연결이 "다르다"고 기술적으로 차단할 수 있습니까? 그렇다면 어떻게 중지합니까? 이 제한을 해제하려면 어떻게 해야 합니까?

(2) 이 연결을 허용하지 않는 다른 이유(방화벽 구성, 라우터 구성, 원본 또는 점프 호스트의 SSH 설정), 다른 이유가 있습니까?

(3) 원본 서버가 대상 서버를 모르기 때문에 첫 번째 ssh 명령이 실패하여 첫 번째 ssh 명령이 예상대로 작동하지 않을 수 있습니까? 즉, 첫 번째 ssh 명령("destination")에 지정된 호스트 이름이 클라이언트(소스) 또는 터널을 생성하기 위해 연결하는 서버(점프 호스트)에서 해석됩니까?

나를 가장 혼란스럽게 하는 것은 점프 호스트에서 대상으로 일반 SSH 세션을 설정하는 것이 가능하다는 것입니다. 전달된 포트를 통해 들어오는 SSH 연결도 동일할 것이라고 생각했지만 어쩐지 그렇지 않습니다.

어떤 조언이라도 대단히 감사하겠습니다.