ekzhang/boreTúnel TCP simples em Rust que expõe portas locais para um servidor remoto, contornando firewalls NAT. Leve, auto-hospedável e fácil de instalar.
Um túnel TCP moderno e simples em Rust que expõe portas locais para um servidor remoto, contornando firewalls de conexão NAT padrão. Isso é tudo o que ele faz: nada mais, nada menos.
# Instalação (requer Rust, veja alternativas abaixo)
cargo install bore-cli
# Na sua máquina local
bore local 8000 --to bore.pub
Isso irá expor sua porta local em localhost:8000 para a internet pública em bore.pub:<PORT>, onde o número da porta é atribuído aleatoriamente.
Similar ao localtunnel e ngrok, exceto que bore é projetado para ser uma ferramenta altamente eficiente e sem opiniões para encaminhamento de tráfego TCP, simples de instalar e fácil de auto-hospedar, sem firulas.
(bore totaliza cerca de 400 linhas de código Rust seguro e assíncrono e é trivial de configurar — basta executar um único binário para o cliente e servidor.)
bore é empacotado como uma fórmula principal do Homebrew.
brew install bore-cli
bore está disponível no AUR como bore.
yay -S bore # ou seu AUR helper favorito
bore está disponível no overlay gentoo-zh.
sudo eselect repository enable gentoo-zh
sudo emerge --sync gentoo-zh
sudo emerge net-proxy/bore
Caso contrário, a maneira mais fácil de instalar o bore é a partir de binários pré-construídos. Eles estão disponíveis na página de releases para macOS, Windows e Linux. Basta descompactar o arquivo apropriado para sua plataforma e mover o executável bore para uma pasta no seu PATH.
Você também pode compilar bore a partir do código-fonte usando Cargo, o gerenciador de pacotes do Rust. Este comando instala o binário bore em um caminho acessível ao usuário.
cargo install bore-cli
Também publicamos imagens Docker versionadas para cada release. A imagem é construída para uma arquitetura AMD 64 bits. Elas são marcadas com a versão específica e permitem executar o binário bore estaticamente vinculado a partir de um contêiner "scratch" mínimo.
docker run -it --init --rm --network host ekzhang/bore <ARGS>
Esta seção descreve o uso detalhado do comando CLI bore.
Você pode encaminhar uma porta em sua máquina local usando o comando bore local. Isso recebe um argumento posicional, a porta local a ser encaminhada, bem como uma opção obrigatória --to, que especifica o endereço do servidor remoto.
bore local 5000 --to bore.pub
Você pode opcionalmente passar uma opção --port para escolher uma porta específica no remoto a ser exposta, embora o comando falhe se essa porta não estiver disponível. Além disso, passar --local-host permite expor um host diferente em sua rede local além do endereço de loopback localhost.
As opções completas são mostradas abaixo.
Inicia um proxy local para o servidor remoto
Uso: bore local [OPÇÕES] --to <TO> <PORTA_LOCAL>
Argumentos:
<PORTA_LOCAL> A porta local a ser exposta [env: BORE_LOCAL_PORT=]
Opções:
-l, --local-host <HOST> O host local a ser exposto [padrão: localhost]
-t, --to <TO> Endereço do servidor remoto para expor portas locais [env: BORE_SERVER=]
-p, --port <PORT> Porta opcional no servidor remoto para selecionar [padrão: 0]
-s, --secret <SECRET> Segredo opcional para autenticação [env: BORE_SECRET]
-h, --help Exibe ajuda
Conforme mencionado nas instruções iniciais, há uma instância pública do servidor bore rodando em bore.pub. No entanto, se você quiser auto-hospedar bore em sua própria rede, pode fazê-lo com o seguinte comando:
bore server
É só isso! Após o servidor começar a rodar em um determinado endereço, você pode então atualizar o comando bore local com a opção --to <ENDEREÇO> para encaminhar uma porta local para este servidor remoto.
É possível especificar endereços IP diferentes para o servidor de controle e para os túneis. Essa configuração é útil para casos em que você pode querer que o servidor de controle esteja em uma rede privada enquanto permite conexões de túnel por uma interface pública, ou vice-versa.
As opções completas para o comando bore server são mostradas abaixo.
Executa o servidor proxy remoto
Uso: bore server [OPÇÕES]
Opções:
--min-port <PORTA_MIN> Número mínimo de porta TCP aceito [env: BORE_MIN_PORT=] [padrão: 1024]
--max-port <PORTA_MAX> Número máximo de porta TCP aceito [env: BORE_MAX_PORT=] [padrão: 65535]
-s, --secret <SECRET> Segredo opcional para autenticação [env: BORE_SECRET]
--bind-addr <ENDEREÇO_VINC> Endereço IP ao qual vincular, os clientes devem alcançá-lo [padrão: 0.0.0.0]
--bind-tunnels <TUNEIS_VINC> Endereço IP onde os túneis escutarão, usa --bind-addr por padrão
-h, --help Exibe ajuda
Há uma porta de controle implícita em 7835, usada para criar novas conexões sob demanda. Na inicialização, o cliente envia uma mensagem "Hello" para o servidor na porta de controle TCP, solicitando o proxy de uma porta remota selecionada. O servidor então responde com um reconhecimento e começa a ouvir por conexões TCP externas.
Sempre que o servidor obtém uma conexão na porta remota, ele gera um UUID seguro para essa conexão e o envia de volta ao cliente. O cliente então abre um fluxo TCP separado para o servidor e envia uma mensagem "Accept" contendo o UUID nesse fluxo. O servidor então faz o proxy das duas conexões entre si.
Por questões de correção e para evitar vazamentos de memória, as conexões recebidas são armazenadas pelo servidor por no máximo 10 segundos antes de serem descartadas se o cliente não as aceitar.
Em uma implantação personalizada do bore server, você pode opcionalmente exigir um segredo para evitar que o servidor seja usado por outros. O protocolo exige que os clientes verifiquem a posse do segredo em cada conexão TCP respondendo a desafios aleatórios na forma de códigos HMAC. (Este segredo é usado apenas para o handshake inicial, e nenhum tráfego adicional é criptografado por padrão.)
# no servidor
bore server --secret minha_string_secreta
# no cliente
bore local <PORTA_LOCAL> --to <TO> --secret minha_string_secreta
Se um segredo não estiver presente nos argumentos, bore também tentará ler da variável de ambiente BORE_SECRET.
Criado por Eric Zhang (@ekzhang1). Licenciado sob a licença MIT.
O autor gostaria de agradecer aos contribuidores e mantenedores do projeto Tokio por tornar possível escrever serviços de rede ergonômicos e eficientes em Rust.