답변:
RDP를 통해 터널링 할 수는 없지만 서버에 rdp하고 클라이언트로 ssh 터널을 다시 시작하면 컴퓨터가 ssh로 연결됩니다. 원격 및 로컬 포트를 모두 전달할 수 있으므로 모두 반대 방향으로 수행 할 수 있습니다.
편집하다
클라이언트 PC에 ssh 서버를 설치하고 포트 443에서 ssh 연결을 허용하도록 설정하면 서버에서 ssh 서버 (클라이언트)에 연결할 수 있고 (ssh 클라이언트 연결 사용) 포트를 열 필요가 없습니다 ( https를 위해 443이 열려 있어야합니다.)
기본 Windows 클라이언트 대신 클라이언트 측에서 rdesktop을 실행중인 경우 rdp2tcp 를 사용할 수 있습니다 .
RDP 연결을 통해 TCP 포트 전달을 관리 할 수 있습니다.
관리자 액세스 또는 인터페이스 대 인터페이스 네트워크 라우팅을 허용하지 않는 Windows Server에서 rdp2tcp 보다 더 나은 것을 찾지 못했습니다 . 이 기능을 사용하려면 rdesktop 에서 OOP 패치 를 수행해야합니다 (최신 버전의 rdesktop에 해당하는 페이지를 찾으려면 마지막 페이지로 이동). MinGW 컴파일러를 사용하여 터널의 Windows 끝을 컴파일했습니다.
문서도 훌륭하고 간결합니다.
사소한 점처럼 보일 수 있습니다. '-'와 함께 'addin'이름을 사용하면 rdesktop이 명령 줄을 올바르게 구문 분석하지 못합니다. 이것은 적절한 탈출을 요구하는 bashism 일 수도 있지만 확실하지 않습니다.
내가 이해할 수있는 한, 이것은 Windows 측에 대한 관리자 권한이 없으면 불가능한 TCP 프로토콜 데이터 단위를 '인식'하는 'true'TCP 터널이 아닙니다. 미리 구성된 엔드 포인트가있는 양말 프록시와 비슷합니다 (결과는 아님). 또한 멋진 양말 프록시가 특징입니다.
나는 그것으로 대화 형 SSH 세션을 쉽게 관리했지만 SSH 파일 전송을 견뎌 내지 못했습니다 (rdesktop 콘솔에서 '가상 채널 연결 끊김') stderr로 변경하지 않음)). RDP2TCP_PING_TIMEOUT이라는 소스에 상수가 있었는데 터널을 유지하기위한 연결 유지 시간 초과처럼 보입니다. 중간 네트워크에서 일종의 조절을 가정하면이를 5 초에서 900 초로 늘리면 트릭을 수행 한 것처럼 보였으며 최대 100MB의 전송 (특정 네트워크에서 약 15 분 소요)을 견뎌냈습니다.
그 외에도 rdp2tcp는 rdesktop 파이프에서 중단으로 인해 수신되었다고 주장하는 SIGPIPE를 발견했지만 rdesktop 코드 또는 ' lsof '는 SIGPIPE 트리거 전후에 rdesktop의 파이프 수에 변화가 없음을 보여주었습니다.
이 경우 rdesktop 및 가능하면 터널의 Windows 쪽도 다시 시작해야합니다. rsync 및 이력서 파일 전송을 사용하고 전체 복구 프로세스를 자동화 할 수 있습니다.
이 모든 것이 리눅스를 클라이언트로 가정하고있었습니다. Cygwin / X와 관련된 일부 관련 문제로 인해 Windows에서 패치 된 rdesktop을 시도하지 않았습니다. 나는 그것이 작동해야한다고 생각합니다.
또한 내 경험은 SSH에 관한 것이지만 다른 방법으로 엄청난 파일 전송은 같은 문제를 겪을 가능성이 있습니다.
로컬 포트 포워딩을 RDP에 사용할 수 있다고 생각합니다.
A -> B -> C
A는 Windows 또는 Mac이고 B는 Linux이고 C는 Windows입니다. A에서 C로 RDP를 원하고 A에서 C로 직접 도달 할 수없는 경우 A에서
ssh username@B -L 7777:C:3389
RD 클라이언트를 연 다음 127.0.0.1:7777에서 C의 사용자 이름과 비밀번호를 사용하십시오. Mac에서 시도했지만 Windows에서는 작동합니다.