tunnel
1.0.0
Encaminhador de porta TCP/UDP seguro e multiplexado usando piping-server de @nwtgck como retransmissão. Projetado principalmente para conexões p2p entre peers atrás de (múltiplos) NAT/firewalls.
Para o caso especial de IPFS , consulte #examples abaixo.
ID: Cada nó recebe um ID exclusivo (base64) -
tunnel -iO ID está vinculado ao hardware (endereço MAC) e às variáveis de ambiente USER, HOME e HOSTNAME. Compartilhe com seus colegas de uma vez por todas. Nota: dois usuários na mesma máquina recebem IDs de nó separados porque suas variáveis USER e HOME são diferentes.
Modo servidor: exponha sua porta local a pares com quem você compartilha qualquer sequência secreta -
tunnel [options] [-u] [-k < shared-secret > ] < local-port >Modo cliente: Encaminhe sua porta local para a porta local exposta do peer -
tunnel [options] [-u] [-k < shared-secret > ] [-b < local-port > ] [-I < IP > ] < peer-ID:peer-port > Se nenhuma porta local for fornecida usando a opção -b , tunnel usará uma porta aleatória não utilizada. A porta utilizada é sempre informada em stdout.
A opção -I é útil quando o cliente está rodando em um laptop que ocasionalmente se conecta à LAN em que o servidor está. Quando o servidor pode ser encontrado na LAN com IP privado = <IP> , tunnel se conecta através da LAN.
Cliente e servidor devem usar o mesmo segredo para poderem se conectar. A string secreta também pode ser passada usando a variável de ambiente TUNNEL_KEY . O segredo passado com -k tem precedência.
O sinalizador -u denota o uso de UDP em vez do TCP padrão. Se usado, deve ser usado por ambos os pares.
Todos os logs estão em stderr por padrão. Com a opção -l <logfile> , entretanto, é possível iniciar tunnel em segundo plano ( modo daemon ) com logs despejados em <logfile> . O ID do processo do daemon é mostrado ao usuário durante a inicialização para que ele possa encerrar o daemon a qualquer momento com
tunnel -K < procID >Opções:
Para obter uma lista completa de opções, consulte: tunnel -h
Baixe com:
curl -LO https://raw.githubusercontent.com/SomajitDey/tunnel/main/tunnelTorne-o executável:
chmod +rx ./tunnelEm seguida, instale em todo o sistema com:
./tunnel -c install Se você não tiver privilégio sudo , poderá instalar localmente:
./tunnel -c install -lPara atualizar a qualquer momento após a instalação:
tunnel -c update Este programa é simplesmente um script bash executável, dependendo das ferramentas GNU padrão, incluindo socat , openssl , curl , mktemp , cut , awk , sed , flock , pkill , dd , xxd , base64 etc., que estão prontamente disponíveis em distribuições Linux padrão.
Se o seu sistema não possui nenhuma dessas ferramentas e você não tem o privilégio sudo necessário para instalá-lo a partir do repositório de pacotes nativo (por exemplo, sudo apt-get install <package> ), tente baixar um binário portátil e instalá-lo localmente em ${HOME}/.bin .
SSH :
O ponto A expõe a porta SSH local -
tunnel -k " ${secret} " 22O ponto B conecta -
tunnel -b 67868 -k " ${secret} " -l /dev/null " ${peerA_ID} :22 " # Daemon due to -l
ssh -l " ${login_name} " -p 67868 localhost IPFS :
Deixe o peer A ter IPFS-peer-ID: 12orQmAlphanumeric . Seu daemon IPFS escuta na porta TCP padrão 4001. Ela o expõe com -
tunnel -k " ${swarm_key} " ipfs swarm_key é qualquer string secreta que o peer A pode usar para controlar quem pode swarm se conectar a ela usando tunnel .
O ponto B agora se conecta ao ponto A para compartilhamento de arquivos ou pubsub ou p2p -
tunnel -k " ${swarm_key} " 12orQmAlphanumericEste último comando swarm se conecta ao par A por meio do relé do servidor de tubulação e continua conectando o swarm a cada poucos segundos em segundo plano para manter a conexão ativa.
tunnel inicia o daemon IPFS em segundo plano, se ainda não estiver ativo.
O caminho para o repositório IPFS pode ser passado com a opção -r . Caso contrário, a variável de ambiente IPFS_PATH ou o caminho padrão ~/.ipfs será usado normalmente. Exemplo: tunnel -r ~/.ipfs -i fornece o ID do par IPFS.
Shell remoto :
Suponha que você precise iniciar comandos regularmente na caixa Linux do seu local de trabalho a partir de sua máquina doméstica. E você não quer/não pode usar o SSH no tunnel por algum motivo.
No computador do local de trabalho, exponha alguma porta TCP local aleatória, por exemplo, 49090 e conecte um shell a essa porta:
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 'De volta à sua casa:
tunnel -l " /dev/null " -b 5000 -k " your secret " " node_id_of_workplace:49090 "
rlwrap nc localhost 5000Usar rlwrap não é uma necessidade. Mas com certeza torna a experiência mais agradável, pois usa GNU Readline e lembra o histórico de entrada (acessível com as teclas de seta para cima/para baixo, semelhantes às suas sessões bash locais).
Redis :
Precisa se conectar a uma instância remota do Redis hospedada por um colega ou por você mesmo? No host remoto, exponha a porta TCP em que redis-server é executado (padrão: 6379), com tunnel .
Na sua máquina local, use tunnel para encaminhar uma porta TCP para a porta remota. Aponte seu redis-cli para a porta local encaminhada.
Abaixo estão alguns casos de uso aleatórios que pude imaginar para tunnel . Em termos gerais, qualquer coisa que envolva passagem de NAT/firewall (por exemplo, WebRTC sem TURN) ou ingresso em uma LAN remota deve ser útil tunnel . Algumas das ideias a seguir são um tanto incompletas, ainda não foram testadas e podem não funcionar, mas mesmo assim estão documentadas aqui, pelo menos por enquanto, apenas por uma questão de inspiração. Se você achou algum deles útil ou inútil, ou encontrou aplicativos totalmente novos para tunnel , poste nas discussões. Os casos que testei são rotulados como "funcionais".
tunnel .tunnel no Heroku (de graça) e encaminhar a porta armazenada na variável de ambiente PORT para a porta local que você deseja expor. E você tem seu URL público como: https://your-app-name.herokuapp.com.tunnel . tunnel criptografa todo o tráfego entre um ponto e a retransmissão com TLS, se a retransmissão usar https. Não há criptografia de ponta a ponta entre os próprios pares. No entanto, afirma-se que o relé do servidor de tubulação não tem armazenamento .
Um ponto cliente pode se conectar com um ponto servidor somente se usar a mesma chave secreta (TUNNEL_KEY). A chave é usada principalmente para descoberta de pares no estágio de retransmissão. Para cada nova conexão com a porta local encaminhada, o cliente envia uma chave de sessão aleatória ao peer servidor. Os pares então formam uma nova conexão em outro ponto de retransmissão com base nesta chave aleatória para que a transferência real de dados ocorra. Estranhos, viz. atores mal-intencionados que não conhecem TUNNEL_KEY não devem ser capazes de interromper esse fluxo.
No entanto, um peer mal-intencionado pode fazer o seguinte. Como ele conhece o TUNNEL_KEY e o ID do nó do par servidor, ele pode personificar o último. Os dados de um par de conexão desavisado, portanto, seriam encaminhados ao imitador, privando o servidor genuíno. Atualizações/implementações futuras do tunnel devem lidar com esta ameaça usando criptografia de chave pública. [Nesse caso, a chave de sessão aleatória gerada para cada nova conexão a ser encaminhada seria descriptografável apenas pelo servidor genuíno].
Dado que tunnel é essencialmente a camada de transporte, os pontos acima não devem ser desanimadores, porque a maioria das aplicações, como SSH e IPFS, criptografam dados na camada de aplicação. A criptografia tunnel de ponta a ponta para todas as transferências de dados só aumentaria a latência. No entanto, você sempre pode criar um túnel SSH depois de estabelecer o peering de baixo nível com tunnel , se desejar.
O relé padrão usado pelo tunnel é https://ppng.io. Você também pode usar algum outro retransmissor público desta lista ou hospedar sua própria instância em serviços gratuitos, como os oferecidos pelo Heroku. Escusado será dizer que, para conectar, dois pares devem usar o mesmo relé.
Se desejar, você também pode escrever seu próprio relé para ser usado pelo tunnel usando ferramentas simples como o sertain. Apenas certifique-se de que seu serviço de retransmissão tenha a mesma API que o piping-server. Se o seu código de retransmissão for de código aberto, você poderá apresentá-lo nas discussões.
soquete g; ipfs p2p com relé de circuito habilitado; go-piping-duplex ; pipeto.me; ligação ascendente; localhost.run; ngrok; túnel local; sshreach.me ( avaliação gratuita apenas por período limitado ); mais
Notas:
tunnel e o servidor de tubulação, no entanto, você pode simplesmente implantar sua própria instância de retransmissão, compartilhar sua URL pública com seus pares de uma vez por todas, export o mesmo que TUNNEL_RELAY dentro de .bashrc e pronto. Além disso, vários servidores de tubulação públicos estão disponíveis para redundância.IPFS (concluído):
Conectar-se ao IPFS seria muito mais simples:
tunnel -k <secret> ipfs para expor e tunnel -k <secret> <IPFS_peerID> para conectar.
Eles iniciarão o daemon IPFS por conta própria, se estiverem offline. O último comando irá conectar-se repetidamente ao peer fornecido em intervalos de 30 segundos. O IPFS-peer-ID será usado como o ID do nó, para que os peers não precisem mais compartilhar seus IDs de nó separadamente. Caminhos de repositório IPFS não padrão podem ser passados com a opção -r . ou IPFS_PATH .
SSH:
Criar um túnel SSH entre a porta local e a porta peer seria tão fácil quanto:
tunnel -k <secret> ssh para expor &
tunnel -sk <secret> -b <local-port> <peerID>:<peer-port> para criar.
Observe que, durante a conexão, não é mais necessário fornecer um nome de login. O ${USER} do nó servidor é considerado o nome de login por padrão. No entanto, se necessário, um nome de login não padrão sempre poderá ser passado usando uma variável ou opção de ambiente.
GPG:
Máquinas virtuais, como as usadas por cloud-shells e dynos, não possuem endereços de hardware exclusivos e persistentes. O ID do nó, portanto, continua mudando de sessão para sessão para tal VM. tunnel futuro teria uma opção -g que passaria uma chave privada GPG para tunnel . O ID do nó seria gerado a partir da impressão digital dessa chave, semelhante ao que o IPFS faz. Isso também tornaria tunnel mais seguro.
Argônio2:
Opção [ -a ] para usar argon2 para hash de TUNNEL_KEY antes do uso, para que um segredo mais fraco não seja muito vulnerável.
Por favor, relate bugs em problemas. Publique seus pensamentos, comentários, ideias, casos de uso e solicitações de recursos na discussão. Deixe-me saber como isso ajudou você, se é que ajudou.
Sinta-se também à vontade para me escrever diretamente sobre qualquer coisa relacionada a este projeto.
Se este pequeno roteiro for útil para você, uma estrela seria imensamente encorajadora para mim.
Obrigado ! ?
