- Tailscale Peer Relays é um novo recurso de relay de tráfego que substitui os servidores DERP existentes, com uma arquitetura que os próprios usuários podem implantar e gerenciar
- Cada nó pode atuar como relay com apenas uma porta UDP aberta, e o recurso pode ser ativado facilmente por estar embutido no cliente Tailscale
- Suporta conexões de alta velocidade e alto throughput, garantindo desempenho próximo de uma conexão direta mesmo atrás de NAT em nuvem ou firewall
- Todo o tráfego mantém criptografia ponta a ponta baseada em WireGuard®, com suporte a fallback automático para DERP e DERP customizado
- No momento, está disponível em beta público, com até 2 Peer Relays gratuitos em todos os planos
Visão geral do Tailscale Peer Relays
- O Tailscale Peer Relays é um mecanismo de relay de tráfego gerenciado pelo usuário que pode substituir os servidores DERP gerenciados da Tailscale
- Qualquer nó do Tailscale pode ser configurado como relay e encaminhar tráfego entre nós do mesmo tailnet
- Um relay só pode encaminhar nós do tailnet ao qual pertence
- Como é administrado diretamente pelo cliente, há menos restrições de throughput do que no DERP, além de oferecer alto desempenho mesmo em infraestruturas de nuvem fechadas ou ambientes com firewall
- Nos testes iniciais com parceiros, registrou throughput próximo ao de conexões diretas, confirmando desempenho dezenas de vezes superior ao DERP existente
Superando ambientes com Hard NAT
- A Tailscale aplica tecnologias avançadas de travessia de NAT para manter conexões diretas (mais de 90%) sempre que possível, mesmo em ambientes com NAT
- Porém, em alguns ambientes de nuvem, conexões diretas podem ser impossíveis ou ineficientes
- O DERP existente fornece conectividade estável, mas há dificuldades em alguns cenários de implantação devido a restrições de QoS e limites de desempenho
- O Peer Relays foi projetado como uma ferramenta de conectividade orientada a desempenho, com comunicação UDP de baixa latência e uma arquitetura embutida no cliente que facilita a implantação
- Os clientes podem posicionar seus próprios relays para montar uma rede de alto desempenho e alta flexibilidade
Como funciona
- O Peer Relay usa uma única porta UDP acessível por ambos os nós
- Pode ser ativado facilmente com o comando CLI
tailscale set --relay-server-port
- Quando a conexão direta não é possível, faz fallback automático na ordem Peer Relay → DERP (gerenciado ou customizado)
- Todas as conexões são protegidas com criptografia WireGuard®
- É possível configurar o sistema para permitir apenas tráfego interno do tailnet, minimizando exceções no firewall
- Também oferece suporte a escalabilidade entre regiões, tolerância a falhas de rede e fallback automático para DERP
Vários cenários de uso
- Relay em alta velocidade para tráfego que não pode se conectar diretamente em ambientes com NAT em nuvem (como AWS Managed NAT Gateway)
- Em ambientes com firewall rigoroso, basta abrir uma única porta UDP para simplificar o processo de aprovação
- Redução da carga da rede DERP e eliminação da necessidade de manter DERP customizado
- Ao acessar redes fechadas de clientes, é possível abrir apenas o mínimo de portas por meio de endpoints previsíveis
- Na prática, clientes já usam Peer Relay para implementar acesso a redes não gerenciadas, controle de rotas de conexão com parceiros e segmentação detalhada de rede baseada em VPC peering
Beta público e política de oferta
- O Tailscale Peer Relays está disponível imediatamente em beta público
- No momento, melhorias adicionais de visibilidade e depuração estão em andamento
- Os parceiros iniciais confirmaram implantação fácil e desempenho estável
- Todos os planos, incluindo o gratuito, incluem até 2 Peer Relays gratuitos, com possibilidade de expansão para relays adicionais
- Se precisar de mais relays, a expansão pode ser feita entrando em contato com a equipe comercial da Tailscale
1 comentários
Opiniões no Hacker News
Acho que esse recurso faz muito sentido
A estrutura usa um nó intermediário só quando a conexão direta é impossível, e o tráfego é criptografado de ponta a ponta
É parecido com operar seu próprio servidor DERP, mas sem precisar abrir portas, além de reduzir o uso dos relays da Tailscale e economizar custos de banda
Só fico curioso por que usar mais de dois relays é pago
Se não for assim, talvez você nem precise de tailscale para começo de conversa
Como exceção, há casos em que dois clientes conseguem acessar o relay, mas não conseguem se conectar diretamente entre si
O antigo tinc já resolvia esse problema
Todos os nós podem atuar como relay, e ele funciona como uma verdadeira rede mesh sem servidor central
Em vez de reimplementar isso, acho melhor portar para uma linguagem com segurança de memória baseada em wireguard
Muitas vezes a rota cai logo depois de estabelecer a conexão SSH
Como a estrutura faz descriptografia e recriptografia no nó relay, para ter criptografia de ponta a ponta é preciso usar um protocolo experimental
Eu gostaria de reescrever isso com base no protocolo cjdns, mas não é fácil
O novo recurso Peer Relay da Tailscale parece parecido com o que a ZeroTier fazia no passado
É difícil dizer que isso é um “recurso exclusivo da Tailscale”, e cobrar a mais além da tarifa por usuário parece exagerado
Em vez disso, os problemas eram o próprio esquema de criptografia, a queda de desempenho em thread única e a lentidão no desenvolvimento
Já testei várias alternativas, mas ainda não vi nada que reúna funcionalidade e desempenho como a Tailscale
A comparação soa como “se existe FTP, por que usar Dropbox?”
Fico curioso se é possível especificar diretamente endereços IPv4/IPv6 externos
Isso porque o tráfego de envio e recebimento pode usar endereços diferentes, ou porque só alguns endereços entre várias conexões de internet são permitidos pelo firewall
Na semana passada configurei headscale e split horizon SSL, mas acabei descobrindo que só DERP funciona
Acho melhor expor diretamente uma porta UDP na rede local
Se a segurança do cliente Wireguard já foi suficientemente validada, isso é bem mais prático
Queria perguntar se você tentou abrir diretamente a porta do Wireguard ou se estava falando da porta do Tailscale
Se você usar esse recurso no lugar de DERP, ele não funciona no navegador
Isso acontece porque ele é baseado em UDP nativo
Fico curioso se no futuro isso poderia ser implementado com WebTransport
Mas isso não resolve o problema de NAT traversal
Também estou acompanhando de perto o progresso do QAD da Iroh
Se tudo se encaixar, acho que a rede vai ficar muito mais mágica
Fico pensando se o próximo passo seria todos os clientes tailscale aceitarem automaticamente solicitações de encaminhamento, para que a rede mesh se autorrecupere sem interrupções
Mas o ponto principal é decidir se será permitido fazer relay do tráfego de outras pessoas
A Tailscale permite conectar serviços entre si, mas se houver uma falha na Tailscale, fico curioso se até a comunicação entre meus próprios serviços cai
Não dava nem para reconectar ao tailscale
Por isso agora pretendo montar meu próprio headscale
Foi meio absurdo nem os dispositivos da LAN local conseguirem se comunicar
Passei o fim de semana inteiro criando uma solução temporária para o Kubernetes Operator, e agora vou poder jogar tudo fora graças a esse recurso
Realmente, bravo
Eu estava curioso sobre o caso de uso desse recurso
Parece algo para quando um produto SaaS precisa de dados do sistema do cliente, e o lado do cliente expõe os dados por meio de um relay para integração
Ainda assim, parece que algum software para autenticação, logging etc. continuaria sendo necessário
Como muitas vezes não dá para contornar o NAT, o DERP é usado com frequência, mas é lento
Agora dá para designar como relay um peer dentro da rede com boa conectividade e usar isso com mais velocidade
Não é tanto um novo caso de uso, mas sim uma versão com melhor desempenho do DERP existente
Em vez da estrutura tradicional hub-and-spoke, ela busca uma arquitetura P2P em que todos os nós se conectem diretamente por UDP/IP sempre que possível
Mas por causa de NAT e firewall, muitas vezes a conexão direta não funciona, e o DERP faz essa mediação
O DERP era lento e o usuário não tinha como melhorar o desempenho, mas com este Peer Relay agora dá para operar seu próprio relay
Se a localização for bem escolhida, também dá para reduzir a latência
Claro que não é um recurso necessário para todos os usuários