tunnel 다운로드 - tunnel 소스 코드 다운로드

tunnel

기타 카테고리

1.0.0

다운로드

터널

@nwtgck의 파이프 서버를 릴레이로 사용하는 안전한 다중화 TCP/UDP 포트 전달자입니다. (다중) NAT/방화벽 뒤에 있는 피어 간의 p2p 연결을 위해 주로 설계되었습니다.

특징

피어 간의 TCP/UDP 터널. 각 피어는 (여러) NAT 뒤에 있을 수 있습니다. 즉, 공용 인터넷에서 연결할 수 없습니다.
나가는 http(s) 연결만 사용되므로 방화벽은 문제를 일으키지 않습니다.
보안: 연결하려면 피어는 서비스 제공 피어의 고유 ID와 공유 비밀 키를 알아야 합니다. 피어와 릴레이 간의 트래픽은 암호화됩니다(TLS). 릴레이는 아무것도 저장하지 않습니다.
멀티플렉싱: 각 터널은 여러 개의 동시 연결을 지원합니다. 연결은 전이중입니다.
다대일: 전달 피어는 클라이언트 역할을 하고 전달 피어는 서버 역할을 합니다. 서버는 언제든지 여러 클라이언트를 지원할 수 있습니다. 각 노드는 서버와 클라이언트 역할을 모두 수행할 수 있습니다.
복원력: 간헐적인 연결이 발생하는 경우 피어가 자동으로 다시 연결됩니다.
슈퍼유저 권한이 필요하지 않습니다.
자체 릴레이 서버를 호스팅하는 옵션(쉽게 무료).
KISS: 하나의 작고 휴대 가능한 쉘 스크립트입니다.
설치 프로그램 및 업데이트 프로그램이 내장되어 있습니다.

명령줄

IPFS 의 특별한 경우는 아래 #examples를 참조하세요.

ID: 모든 노드에는 고유한(base64) ID가 부여됩니다.

tunnel -i

ID는 하드웨어(MAC 주소)와 환경 변수 USER, HOME 및 HOSTNAME에 바인딩됩니다. 동료들과 한번에 공유해보세요. 참고: 동일한 시스템에 있는 두 명의 사용자에게는 USER 및 HOME 변수가 다르기 때문에 별도의 node-ID가 제공됩니다.

서버 모드: 비밀 문자열을 공유하는 피어에게 로컬 포트를 노출합니다.

tunnel [options] [-u] [-k < shared-secret > ] < local-port >

클라이언트 모드: 로컬 포트를 피어의 노출된 로컬 포트로 전달 -

tunnel [options] [-u] [-k < shared-secret > ] [-b < local-port > ] [-I < IP > ] < peer-ID:peer-port >

-b 옵션을 사용하여 로컬 포트가 제공되지 않으면 tunnel 사용되지 않는 임의의 포트를 사용합니다. 사용된 포트는 항상 stdout에 보고됩니다.

-I 옵션은 때때로 서버가 있는 LAN에 연결되는 랩톱에서 클라이언트를 실행하는 경우 유용합니다. 개인 IP = <IP> 로 LAN에서 서버를 찾을 수 있으면 tunnel LAN을 통해 연결됩니다.

클라이언트와 서버는 서로 연결하려면 동일한 비밀을 사용해야 합니다. 비밀 문자열은 환경 변수 TUNNEL_KEY 사용하여 전달될 수도 있습니다. -k 로 전달된 비밀이 우선합니다.

-u 플래그는 기본 TCP 대신 UDP 사용을 나타냅니다. 사용하는 경우 두 피어 모두에서 사용해야 합니다.

모든 로그는 기본적으로 stderr에 있습니다. 그러나 -l <logfile> 옵션을 사용하면 <logfile> 에 덤프된 로그를 사용하여 백그라운드( 데몬 모드 )에서 tunnel 시작할 수 있습니다. 데몬 프로세스 ID는 실행 중에 사용자에게 표시되므로 언제든지 데몬을 종료할 수 있습니다.

tunnel -K < procID >

옵션:

전체 옵션 목록을 보려면 tunnel -h 참조하세요.

설치 및 업데이트

다음으로 다운로드하세요:

curl -LO https://raw.githubusercontent.com/SomajitDey/tunnel/main/tunnel

실행 가능하게 만드세요:

chmod +rx ./tunnel

그런 다음 다음을 사용하여 시스템 전체에 설치하십시오.

./tunnel -c install

sudo 권한이 없으면 대신 로컬로 설치할 수 있습니다.

./tunnel -c install -l

설치 후 언제든지 업데이트하려면:

tunnel -c update

종속성/이식성

이 프로그램은 표준 Linux 배포판에서 쉽게 사용할 수 있는 socat , openssl , curl , mktemp , cut , awk , sed , flock , pkill , dd , xxd , base64 등을 포함한 표준 GNU 도구에 따라 실행 가능한 bash 스크립트일 뿐입니다.

시스템에 이러한 도구가 없고 기본 패키지 저장소(예: sudo apt-get install <package> )에서 이를 설치하는 데 필요한 sudo 권한이 없는 경우 휴대용 바이너리를 다운로드하여 ${HOME}/.bin 에서 로컬로 설치해 보세요. ${HOME}/.bin .

예

SSH :

피어 A는 로컬 SSH 포트를 노출합니다.

tunnel -k " ${secret} " 22

피어 B가 연결됩니다 -

tunnel -b 67868 -k " ${secret} " -l /dev/null " ${peerA_ID} :22 " # Daemon due to -l
ssh -l " ${login_name} " -p 67868 localhost

IPFS :

피어 A에 IPFS-peer-ID: 12orQmAlphanumeric 이 있다고 가정합니다. 그녀의 IPFS 데몬은 기본 TCP 포트 4001에서 수신 대기합니다. 그녀는 이를 다음과 같이 노출합니다.

tunnel -k " ${swarm_key} " ipfs

swarm_key 는 피어 A tunnel 사용하여 자신에게 스웜 연결할 수 있는 사람을 제어하는 데 사용할 수 있는 비밀 문자열입니다.

이제 피어 B는 파일 공유, pubsub 또는 p2p를 위해 피어 A와 연결됩니다.

tunnel -k " ${swarm_key} " 12orQmAlphanumeric

이 마지막 명령 떼는 파이핑 서버 릴레이를 통해 피어 A에 연결하고 연결을 유지하기 위해 백그라운드에서 몇 초마다 떼 연결을 유지합니다.

tunnel 아직 활성화되지 않은 경우 백그라운드에서 IPFS 데몬을 시작합니다.

IPFS 저장소 경로는 -r 옵션을 사용하여 전달할 수 있습니다. 그렇지 않으면 환경 변수 IPFS_PATH 또는 기본 경로 ~/.ipfs 가 평소대로 사용됩니다. 예: tunnel -r ~/.ipfs -i IPFS 피어 ID를 제공합니다.

원격 쉘 :

집에 있는 컴퓨터에서 직장 Linux 상자에 정기적으로 명령을 실행해야 한다고 가정해 보겠습니다. 그리고 어떤 이유로 tunnel 통해 SSH를 사용하고 싶지 않거나 사용할 수 없습니다.

작업장 컴퓨터에서 임의의 로컬 TCP 포트(예: 49090)를 노출하고 해당 포트에 셸을 연결합니다.

tunnel -l " /tmp/tunnel.log " -k " your secret " 49090 # Note the base64 node id emitted
socat TCP-LISTEN:49090,reuseaddr,fork SYSTEM: ' bash 2>&1 '

집으로 돌아오세요:

tunnel -l " /dev/null " -b 5000 -k " your secret " " node_id_of_workplace:49090 "
rlwrap nc localhost 5000

rlwrap을 사용할 필요는 없습니다. 그러나 GNU Readline을 사용하고 입력 기록을 기억하므로(로컬 bash 세션과 유사한 위쪽/아래쪽 화살표 키로 액세스 가능) 경험이 더 달콤해집니다.

레디스 :

피어나 자신이 호스팅하는 원격 Redis 인스턴스에 연결해야 합니까? 원격 호스트에서 tunnel 사용하여 redis-server 실행되는 TCP 포트(기본값: 6379)를 노출합니다.

로컬 머신에서 tunnel 사용하여 TCP 포트를 원격 포트로 전달합니다. redis-cli 전달된 로컬 포트를 가리키도록 하세요.

응용

다음은 내가 생각할 수 있는 tunnel 사용 사례 중 일부입니다. 광범위하게 말하면 NAT/방화벽 통과(예: TURN 없는 WebRTC) 또는 원격 LAN 연결과 관련된 모든 작업에 tunnel 유용할 것입니다. 다음 아이디어 중 일부는 다소 개략적이고 전혀 테스트되지 않았으며 작동하지 않을 수 있지만 그럼에도 불구하고 적어도 당분간 영감을 위해 여기에 문서화되어 있습니다. 이들 중 유용하거나 쓸모없는 것이 있거나 완전히 새로운 tunnel 애플리케이션을 발견했다면 토론에 게시해 주세요. 내가 테스트한 사례에는 "작동 중"이라는 표시가 있습니다.

IPFS 피어에 연결 중( 작업 중 )
P2P 채팅, 메일링, VoIP, 스트리밍, 게임, 화면 공유, 파일 공유, 도박, 문제 해결 등.
IOT 장치를 연결합니다.
SSH( 작업 ), RDP 또는 VNC를 사용하여 워크스테이션을 가정용 컴퓨터 또는 노트북과 연결합니다.
조개 삽질( 작업 중 ).
자체 호스팅 또는 피어 제공 VPN으로 방화벽을 극복하세요.
인터넷을 통해 집에서 인트라넷 사무실 채팅(사무실 LAN을 통해)에 참여합니다. 예를 들어 BeeBEEP 및 LAN Messenger는 tunnel 사용하여 사무실 내부 노드에서 전달된 로컬 포트를 사용할 수 있습니다.
P2P(서버리스) 오디오/비디오. 예를 들어, 로컬 TCP/UDP 포트를 피어의 localhost로 전달하고 p2p 클라이언트가 이를 가리키도록 합니다. 기성품 FOSS: Jami, Jitsi, Toxchat 및 Retroshare.
Teamviewer 또는 Anydesk를 사용한 서버리스 원격 제어. 로컬 포트(예: 6000)를 피어의 로컬 TCP 포트 5938(TV용) 및 7070(Anydesk용)으로 전달하고 127.0.0.1:6000을 피어의 IP:port 튜플로 사용합니다.
공개적으로 액세스할 수 있는 로컬(웹) 포트 만들기(인터넷에서 액세스할 수 있는 역방향 프록시 라고도 함 ): Heroku에서 무료로 tunnel 실행하고 환경 변수 PORT 에 저장된 포트를 노출하려는 로컬 포트로 전달하기만 하면 됩니다. 공개 URL은 https://your-app-name.herokuapp.com입니다.
범용 네트워크 카메라 어댑터를 사용하여 원격 IP 웹캠에서 피드에 액세스: WLAN을 통해 모바일 캠에 액세스할 수 있는 원격 노드로 로컬 포트를 전달합니다.
VLC로 스트리밍: 영화 및 음악, 웹캠 [명령줄]. tunnel 사용하여 서버와 클라이언트를 연결하기만 하면 됩니다.

보안

tunnel 릴레이가 https를 사용하는 경우 피어와 릴레이 간의 모든 트래픽을 TLS로 암호화합니다. 피어 자체 간에는 종단 간 암호화가 없습니다. 그러나 파이핑-서버 릴레이는 스토리지가 없다고 주장됩니다.

클라이언트 피어는 동일한 비밀 키(TUNNEL_KEY)를 사용하는 경우에만 제공 피어와 연결할 수 있습니다. 키는 주로 릴레이 단계에서 피어 검색에 사용됩니다. 전달된 로컬 포트에 대한 모든 새 연결에 대해 클라이언트는 임의의 세션 키를 서비스 피어에 보냅니다. 그런 다음 피어는 실제 데이터 전송이 발생하도록 이 무작위 키를 기반으로 다른 중계 지점에서 새로운 연결을 형성합니다. 외부인, 즉. TUNNEL_KEY를 모르는 악의적인 행위자가 이 흐름을 방해해서는 안 됩니다.

그러나 악의적인 피어는 다음을 수행할 수 있습니다. 그는 TUNNEL_KEY와 서비스 제공 피어의 노드 ID를 알고 있으므로 후자를 가장할 수 있습니다. 따라서 의심하지 않는 연결 피어의 데이터가 가장하는 사람에게 전달되어 실제 서버가 부족해집니다. tunnel 의 향후 업데이트/구현에서는 공개 키 암호화를 사용하여 이 위협을 처리해야 합니다. [이 경우 전달될 모든 새 연결에 대해 생성된 임의 세션 키는 정품 서버에서만 해독 가능합니다].

tunnel 이 본질적으로 전송 계층이라는 점을 감안할 때 SSH 및 IPFS와 같은 대부분의 애플리케이션은 애플리케이션 계층에서 데이터를 암호화하기 때문에 위의 사항이 낙담해서는 안 됩니다. 모든 데이터 전송에 대해 tunnel 종단 간 암호화는 대기 시간만 증가시킵니다. 그러나 원하는 경우 tunnel 과 낮은 수준의 피어링을 설정한 후 언제든지 SSH 터널을 생성할 수 있습니다.

계전기

tunnel 에서 사용되는 기본 릴레이는 https://ppng.io입니다. 또한 이 목록의 다른 공개 릴레이를 사용하거나 Heroku에서 제공하는 것과 같은 무료 서비스에서 자체 인스턴스를 호스팅할 수도 있습니다. 말할 필요도 없이 연결하려면 두 피어가 동일한 릴레이를 사용해야 합니다.

원하는 경우 sertain과 같은 간단한 도구를 사용하여 tunnel 에서 사용할 릴레이를 직접 작성할 수도 있습니다. 릴레이 서비스에 파이핑 서버와 동일한 API가 있는지 확인하세요. 릴레이 코드가 오픈 소스인 경우 토론에서 소개하는 것이 가장 좋습니다.

또한보십시오

g소켓 ; 회로 릴레이가 활성화된 ipfs p2p; go-piping-duplex ; 파이프토.me ; 업링크 ; 로컬호스트.실행; 응록 ; 로컬 터널 ; sshreach.me( 제한된 기간 동안만 무료 평가판 ); 더

참고:

파이핑 서버와 달리 이들 중 대부분은 가장 중요한 릴레이 또는 역방향 프록시의 쉽고 무료 자체 호스팅을 제공하지 않습니다. 이러한 서비스가 중단되면 운명이 결정됩니다. 그러나 tunnel 및 파이핑 서버를 사용하면 자신만의 릴레이 인스턴스를 배포하고 공개 URL을 동료와 완전히 공유할 수 있으며 .bashrc 내에서 TUNNEL_RELAY 와 동일하게 export 됩니다. 또한 중복성을 위해 여러 공용 파이핑 서버를 사용할 수 있습니다.
무료 계층의 이러한 서비스 중 일부는 모든 세션에 대해 새로운 무작위 공개 URL을 제공하는데, 이는 간헐적인 연결(예: IOT 애플리케이션)에 문제가 됩니다. 일부 무료 요금제는 연결이 유휴 상태가 아니더라도 특정 시간이 지나면 세션이 만료됩니다.
일부는 웹 트래픽에만 로컬 포트를 노출합니다. HTTP를 통해 웹이 아닌 프로토콜을 전송하는 책임은 귀하와 귀하의 동료에게 있습니다.

향후 방향

IPFS(완료):

IPFS에 연결하는 것이 훨씬 간단합니다.

tunnel -k <secret> ipfs 노출하고 tunnel -k <secret> <IPFS_peerID> 연결합니다.

오프라인인 경우 IPFS 데몬이 자체적으로 실행됩니다. 후자의 명령은 30초 간격으로 지정된 피어에 반복적으로 무리 연결을 수행합니다. IPFS-peer-ID가 노드 ID로 사용되므로 피어는 더 이상 노드 ID를 별도로 공유할 필요가 없습니다. 기본이 아닌 IPFS 저장소 경로는 -r 옵션을 사용하여 전달될 수 있습니다. 또는 IPFS_PATH .

SSH:

로컬 포트와 피어 포트 사이에 SSH 터널을 만드는 것은 다음과 같이 쉽습니다.

tunnel -k <secret> ssh 사용하여 노출 &

tunnel -sk <secret> -b <local-port> <peerID>:<peer-port> 생성합니다.

연결하는 동안 더 이상 로그인 이름을 제공할 필요가 없습니다. 기본적으로 서빙 노드의 ${USER} 로그인 이름으로 사용됩니다. 그러나 필요한 경우 환경 변수나 옵션을 사용하여 기본이 아닌 로그인 이름을 항상 전달할 수 있습니다.

GPG:

Cloud-Shell 및 dynos에서 사용되는 가상 머신에는 지속적이고 고유한 하드웨어 주소가 없습니다. 따라서 노드 ID는 해당 VM에 대해 세션마다 계속 변경됩니다. 향후 tunnel GPG 개인 키를 tunnel 에 전달하는 -g 옵션이 있습니다. 노드 ID는 IPFS가 수행하는 것과 유사하게 이 키의 지문에서 생성됩니다. 이는 또한 tunnel 더욱 안전하게 만들 것입니다.

아르곤2:

옵션 [ -a ]는 사용하기 전에 TUNNEL_KEY를 해싱하기 위해 argon2를 사용하여 더 약한 비밀이 너무 취약하지 않도록 합니다.