Dumb Pipe - conectando dois computadores por um pipe

• Dumbpipe é uma ferramenta no estilo Unix que permite conectar facilmente um pipe de dados entre dois computadores
• A instalação e o uso são muito simples, sem necessidade de conta nem configuração adicional
• Em um computador, ele fica em espera no modo receptor e fornece uma chave secreta e o comando de conexão
• No outro computador, é possível enviar e conectar com uma única linha de comando para transferir os dados
• Funciona independentemente do ambiente de rede, podendo ser usado em qualquer lugar

---

Apresentando o Dumbpipe

• Ferramenta open source que permite trocar dados diretamente entre dois computadores no estilo de um pipe Unix
• Como pode ser instalada e executada com uma única linha, sem configurações complexas, é prática e bastante acessível

Principais características

• Após instalar em um computador, é possível entrar no modo de espera (recepção) com o comando ./dumbpipe listen
  • Ao executar, são fornecidos automaticamente uma chave secreta gerada e um comando de conexão dedicado para acesso a partir do outro computador
• O remetente pode enviar dados com facilidade no formato echo "hello" | ./dumbpipe connect ...
• Não é necessário criar uma conta
  • Pode ser usado imediatamente, sem cadastro, login ou registro de informações do usuário
• Funciona imediatamente sem configuração extra
  • Pode ser usado na hora, sem variáveis de ambiente, arquivos de configuração ou ajustes de firewall
• Envio e recebimento de dados entre dois dispositivos em qualquer lugar do mundo
  • Funciona sem restrições de ambiente de rede, seja em rede privada, cloud ou rede local

Resumo do uso

• O receptor executa o dumbpipe em modo listen e copia/compartilha a chave e outras informações necessárias para a conexão
• O remetente usa o comando connect com essa chave para transmitir os dados em forma de stream

Implicações práticas

• Até novos usuários ou pessoas com pouca experiência conseguem montar facilmente um pipeline de transferência de dados em rede
• Pode ser aplicado rapidamente a vários usos, como envio de arquivos ou mensagens simples, retransmissão de dados entre dispositivos, desenvolvimento e automação de deploy
• Com um único comando e um fluxo de trabalho intuitivo, contribui para a produtividade de engenheiros

[GN⁺]

Comentários do Hacker News

• Apresenta uma forma de trocar comandos remotamente usando ssh e socat ou mkfifo

  # receptor
  socat UNIX-RECV:/tmp/foobar - | my-command
  
  # remetente
  my-command | ssh host socat - UNIX-SENDTO:/tmp/foobar
  

  Se o destino estiver bloqueado por firewall ou NAT, é possível usar um servidor SSH público como o ssh-j.com como relay para enviar e receber dados com segurança (usando tunelamento SSH duplo)

  # receptor
  ssh [e-mail] -N -R ssh:22:localhost:22
  socat UNIX-RECV:/tmp/foobar - | my command
  
  # remetente
  my-command | ssh -J [e-mail] ssh socat - UNIX-SENDTO:/tmp/foobar
  

  Isso foi postado originalmente em uma thread sobre beam link

  • Se usar uma ferramenta chamada spiped, isso pode ser implementado de forma mais simples sem depender de ssh site oficial do spiped
  • Essa abordagem não atende aos principais objetivos descritos pelo dumbpipe. Por exemplo, não usa QUIC, também não evita relays quando possível, e não tem seleção automática de relay nem manutenção da conexão conforme a rede muda. Além disso, o gerenciamento de chaves SSH fica por conta do usuário, enquanto o dumbpipe fornece a chave como uma string ASCII arbitrária. WireGuard é mais parecido com o dumbpipe
  • Primeira frase do link de apresentação do dumbpipe:

    Dumb pipe punches through NATs, using on-the-fly node identifiers. It even keeps your machines connected as network conditions change.
    

  • Se você montar um servidor wg para conectar dois clientes, pode encaminhar dados para os IPs de cada um, mas no fim ainda há um relay central intermediando os dados (independentemente de haver NAT ou não)
  • Só agora descobri o ssh-j.com, e achei bem interessante

• Fico curioso por que trocar arquivos de forma simples entre dois PCs usando apenas um cabo USB não é algo padronizado. Se todos os sistemas operacionais suportassem o mesmo protocolo, isso parece o tipo de recurso que deveria existir desde o começo. Sei que cabos USB A-A teoricamente não existem, mas isso por si só reforça a necessidade. Com USB-C isso deveria ser perfeitamente possível; entre Android e PC isso até funciona em certa medida, mas entre dois notebooks não

  • Ao conectar dois dispositivos por USB-C (USB4/Thunderbolt), uma conexão de rede é criada. Por padrão, eles recebem apenas endereços link-local, então usar SSH e afins dá um pouco mais de trabalho, mas com descoberta automática de rede isso funciona bem. Referências: Thunderbolt Networking on Linux, resposta no SuperUser
  • Já existia no Nintendo DS uma tecnologia que fazia isso sem fio, sem cabo e sem LAN. Nos últimos 40 anos, o problema de transferência de arquivos já foi resolvido de inúmeras formas, mas às vezes parece que algumas pessoas não querem que isso seja resolvido de vez sem depender de serviços em nuvem. O dumbpipe é interessante, mas pode acabar esbarrando nas mesmas barreiras práticas de tantas soluções anteriores. Por exemplo, mesmo que um usuário Linux queira mandar um arquivo de 50 MB para um usuário Windows, não há como o lado Windows receber sem instalar algum programa adicional
  • O USB é estruturalmente assimétrico, com separação entre host e dispositivo. O dispositivo funciona como um escravo em polling. A conexão direta por cabo entre dois PCs já era um problema resolvido com Ethernet antes mesmo do USB
  • Antes de o TCP/IP virar padrão universal, arquivos grandes eram transferidos com cabos Ethernet crossover. Hoje muitos PCs estão deixando de ter porta Ethernet, e isso está relacionado a uma visão em que o dono deve subir seus próprios arquivos para computadores de terceiros na internet (a nuvem). Com o tempo surgiram várias formas de transferir arquivos, mas o método com cabo crossover continua funcionando muito bem, e basta ter adaptadores USB para Ethernet. Não precisa de software especial, roteador, internet nem terceiros. Só TCP/IP já basta
  • No Linux isso é possível criando um endpoint MTP, como em dispositivos móveis uMTP-Responder
    A MS também lançou uma ferramenta com esse suporte, mas aparentemente ela existia apenas para Windows CE link oficial da MS

• Relacionado a isso, tenho uma lista de ferramentas de transferência de arquivos que organizei (principalmente baseadas em navegador, com um pouco de CLI). Compartilho quando surge a ocasião e sigo procurando ferramentas boas para adicionar minha lista de ferramentas

  • Prefiro o LocalSend. Ele é excelente para transferências rápidas entre seus próprios dispositivos e funciona bem em todos os sistemas operacionais GitHub do LocalSend
  • A equipe que criou o dumbpipe também fez o Sendme, que foi projetado muito mais especificamente para esse caso de uso GitHub do Sendme

• Fico pensando quanto de implementação se sobrepõe entre dumbpipe e Tailscale. Parece haver muita funcionalidade em comum entre os dois, então imagino que já existam várias bibliotecas utilizáveis nesse nível mais baixo, como para atravessar NAT. Ou talvez esta seja a primeira biblioteca desse tipo

  • Se for por esse critério, o próprio Tailscale já seria a 600ª implementação da mesma ideia. Antes dele já existiam nebula, tinc e outros. A diferença é que ele surgiu no momento em que o WireGuard estava ganhando espaço, com muito marketing e ainda por cima dinheiro de VC
  • O Iroh é muito mais apropriado para a camada de aplicação. Dá para multiplexar vários streams QUIC com finalidades diferentes dentro de uma única conexão. Basta ter acesso ao QUIC, sem precisar de interface de rede virtual. Um exemplo semelhante seria o gRPC, mas com liberdade total para controlar byte streams: um stream pode ser uma chamada de voz, outro transferência de arquivo, outro um RPC simples, tudo dividido em tempo real. É o mais parecido com WebRTC, mas oferece mais opções que SCTP ou RTMP
  • Isto foi feito com iroh e tem como objetivo ser um framework de baixo nível para software distribuído. Além de rede, inclui várias estruturas de dados necessárias para replicação de dados e manutenção de consistência
  • Conectar meu celular via Tailscale em rede móvel/CGNAT foi uma daquelas raras experiências de software do tipo “uau, agora entendi”
  • Vejo o tailscale como um wrapper sobre o WireGuard com algumas funcionalidades extras de hole punching

• No pico.sh, uma funcionalidade parecida de transferência de arquivos foi implementada usando SSH pipe.pico.sh

  • Fico curioso sobre como seria um benchmark direto com o dumbpipe em termos de desempenho e usabilidade

• Se você se interessa pelo ecossistema de ferramentas de tunelamento semelhantes a esta, há uma lista awesome que vale consultar awesome-tunneling

• O iroh é realmente uma tecnologia fantástica. Participei do workshop do Rüdiger (N0) no web3 summit em Berlim há duas semanas e saí muito inspirado. O código para construir um serviço parecido está disponível aqui código do iroh-workshop, e recomendo também dar uma olhada nos slides

• Se você quiser um pipe mais avançado, eu também tenho um CLI de gerenciador de túneis que estou desenvolvendo sobre Iroh. Ele suporta encaminhamento de portas TCP, UDP e sockets UNIX qtm no GitLab

• Soluções desse tipo aparecem uma ou duas vezes por ano. Como um bom projeto open source mais focado em orquestração de conexões, recomendo o Spacebrew documentação oficial do Spacebrew

  • Nesse sentido isso é verdade, mas a identidade visual deste projeto é realmente única. É literalmente um personagem de dumbpipe com braços ridículos. E além disso, simplesmente funciona bem
  • “Em 2023...”

• Sempre achei este método especialmente interessante GitHub do pwnat
  Ele não cobre todos os casos e é um pouco mais complexo, mas tem a grande vantagem de não precisar de intermediário

  • Esta é uma solução bem antiga e às vezes tem problemas com alguns roteadores atuais link da issue
  • GitHub do slipstream é a versão mais nova
  • Nunca tinha visto ferramentas desse tipo antes, mas parecem realmente úteis. Só que, por limitações da própria estrutura do NAT, essa abordagem também tem o lado negativo de permitir que malware abra conexões de entrada mais facilmente, ignorando regras de firewall
  • Acima de tudo, Samy é um herói para mim