NAT 뒤의 한 Linux 시스템에서 다른 Linux 시스템으로 TCP 연결을 전송하시겠습니까?

NAT 뒤의 한 Linux 시스템에서 다른 Linux 시스템으로 TCP 연결을 전송하시겠습니까?

내 HTTP 연결 중 하나가 다운로드 속도가 극도로 느려졌을 때 내 PC에서 동일한 외부 IP 주소를 공유하는 에너지 효율적인 홈 서버로 연결을 이동할 수 있다면 좋겠다고 생각했습니다.

제가 상상하는 대로 특정 IP 및 포트에서 연결을 인계받아 연결의 원래 소유자가 연결을 닫지 않고도 연결을 통해 들어오는 모든 데이터를 파일로 전송할 수 있는 명령을 실행하고 싶습니다.

이미 이 작업을 수행할 수 있는 도구가 있나요?

답변1

대부분의 경우 이는 말이 되지 않습니다. 다운로드를 중단하고 다운로드한 콘텐츠를 서버에 복사한 후 이를 사용하여 wget다운로드를 재개합니다.

답변2

NAT 방화벽 외에도 TCP/IP 연결 작동 방식을 통해 LAN에 있는 여러 컴퓨터 간에 외부 IP 주소를 공유할 수 있기 때문에 이것이 가능하지 않다고 생각합니다. 즉, 작동 방식을 이해하는 한 도움이 될 수 있는 몇 가지 팁/요령이 있습니다.

팁 #1 - 스크린/tmux

일반적으로 다운로드할 대용량 파일이 있으면 ssh네트워크에 있는 다른 컴퓨터로 이동하여 그곳에서 screen/tmux를 실행합니다. screen/tmux 세션을 사용하면 터미널에서 장기 실행 프로그램(예: 다운로드)을 실행할 수 있으며 ssh보조 컴퓨터에서 연결을 끊어도 프로그램이 중지되지 않습니다.

패턴은 다음과 같습니다.

laptop$ ssh remotemachine

...login...

remote$ screen -S mydownload

...now have a screen session called "mydownload"...

remote$ wget http://www.bigfiles.com/somebigfile

...Ctrl+A Ctrl+D.... <--- (disconnect from screensession)

...a little while later...

laptop$ ssh remotemachine
remote$ screen -r mydownload

...wget is still running in here...

팁 #2 – xdg-open

이 프로그램을 사용하면 선호하는 응용 프로그램을 통해 파일 및/또는 URL을 실행할 수 있습니다. 예를 들어, "magnet://" 핸들러와 연결되도록 LAN의 원격 시스템에 Firefox를 설정했습니다. 원격 컴퓨터에서 이 작업을 수행하면 다음과 같은 명령을 실행할 수 있습니다.

ssh remotemachine "DISPLAY=:0.0; xdg-open magnet://url_of_magnet_link...."

내 노트북에서는 원격 컴퓨터가 Firefox를 통해 자석 링크 다운로드를 시작하도록 "트리거"한 다음 Magnet:// 링크 처리와 관련된 응용 프로그램에 URL을 전달합니다. 이 경우 나는비제과정.

이를 위해 Firefox를 설정하는 방법이 궁금하시다면 제가 얼마 전에 제 블로그에 글을 쓴 적이 있습니다. 기사 제목은 다음과 같습니다.[한 줄짜리]: Linux에서 Magnet Link를 통해 Firefox 10.x에서 BitTorrent 클라이언트를 시작하는 방법.

답변3

IP, TCP 및 NAT 관점에서 볼 때 이는 확실히 가능합니다. 서버가 PC의 IP 주소를 얻는 것을 상상할 수 있습니다. 또한 필요한 소켓 데이터 구조와 프로토콜 제어 블록을 초기화하여 연결 전송을 준비하는 서버의 Linux 커널을 상상할 수도 있습니다. 실제 연결 전송에는 두 Linux 커널 간의 조정이 필요합니다.

한 가지 유망한 접근 방식이 존재합니다.TCP 연결 전달. 이는 연결 전달을 위한 소켓 API를 확장하는 커널 패치와 전달 시작을 위한 도구 세트로 구성됩니다. 이 접근 방식은 애플리케이션 계층의 역할을 고려합니다.

사실은 TCP 연결에는 양쪽 끝이 공유하는 애플리케이션 상태도 포함된다는 것입니다. 양 당사자는 상대방이 이 상태에 따라 행동하기를 기대합니다. 따라서 한쪽 끝을 데이터만 흡수하고 아무 응답도 하지 않는 일반 엔터티로 교체하면 오작동으로 인해 상태(및 연결)가 손상될 위험이 있습니다. 이는 설명하는 시나리오에서는 문제가 되지 않을 수 있지만 염두에 두고 있는 일반 연결 전달 체계의 적용 가능성을 제한합니다. 아니요, 그런 것이 존재한다고 생각하지 않습니다. 하지만 TCP 연결 전달은 좋은 시작입니다. 필요에 따라 사용자 정의할 수 있습니다.

관련 정보