Ligar instalações: VPN, Tailscale, NetBird ou Cloudflare Mesh?

Trabalho bastante na interligação de redes empresariais. Surgem regularmente as mesmas perguntas: qual é a melhor solução para ligar as nossas instalações? Precisamos de endereços IP públicos? É segura? E continuará adequada se acrescentarmos uma filial, mudarmos o acesso à Internet ou contratarmos mais pessoas?

A minha resposta depende das necessidades reais da empresa. Duas instalações fixas com firewalls existentes partem de condições diferentes de várias pequenas filiais com ligações variáveis. Também há questões para além do túnel: quem o opera, onde se controlam os acessos e que dependências a empresa aceita manter.

Prefiro compreender a arquitetura antes de escolher um produto. Uma VPN site-to-site tradicional pode ser adequada. Tailscale ou NetBird podem simplificar a gestão e o estabelecimento das ligações. Cloudflare Mesh transfere o percurso dos dados para a rede do fornecedor. Estas diferenças determinam onde cada abordagem faz sentido para mim.

O tema principal é ligar redes completas de instalações. O acesso individual dos colaboradores a partir de casa surge separadamente como utilização adicional de acesso remoto.

O nosso exemplo: Três redes interligadas

A sede utiliza 10.1.0.0/24, a filial 10.2.0.0/24 e o laboratório doméstico 10.3.0.0/24. Cada local dispõe de uma gateway que permite alcançar redes remotas. As impressoras e os NAS por detrás dela não precisam de cliente VPN. Todos os modelos procuram o mesmo objetivo: conectividade controlada entre estas três redes.

Obtém-se uma rede encaminhada de camada 3. As instalações não partilham automaticamente um domínio de difusão e nem todos os protocolos de descoberta local funcionam entre locais. O DNS deve resolver corretamente os nomes internos e os routers locais precisam de rotas para as redes remotas.

Quero primeiro saber de que serviços necessita cada rede. A filial pode precisar do servidor de ficheiros sem aceder à administração do laboratório. O servidor de cópias precisa do destino, mas não de todos os dispositivos do outro local. Estas decisões continuam necessárias em qualquer opção.

Site-to-site descreve a ligação, não a topologia

Site-to-site significa rede a rede. Não obriga a encaminhar todo o tráfego por uma firewall central. A topologia hub-and-spoke através da sede é comum; túneis diretos entre pares de locais também são site-to-site. As gateways de Tailscale, NetBird ou Cloudflare Mesh podem cumprir essa função.

Tailscale e NetBird procuram percursos diretos para os dados, mesmo com registo e coordenação centralizados. A rede Cloudflare está distribuída geograficamente, mas o tráfego entre instalações continua a atravessá-la. Não é uma ligação direta entre pares. A rede do fornecedor substitui a firewall central como ponto de trânsito.

IP públicos e requisitos que mudam

A questão do IP público costuma surgir cedo. Distingo a acessibilidade externa da estabilidade do endereço. Um IP público fixo facilita planear um endpoint VPN acessível. Não é necessário em todos os locais. Uma filial pode iniciar um túnel de saída para uma gateway central acessível; conforme o desenho, o DNS dinâmico ajuda com endereços variáveis.

É mais difícil quando ambos os extremos estão atrás de NAT de operador restritivo e não existe um endpoint diretamente acessível. Sobretudo em acessos móveis, convém verificar os endereços e ligações de entrada realmente disponibilizados pelo operador. Tailscale e NetBird tentam estabelecer ligações diretas através do NAT e utilizam relays se necessário. Cloudflare Mesh estabelece ligações de saída para a rede do fornecedor.

Também quero que a próxima alteração continue controlável. Um novo local, outro operador ou uma ligação sem acesso de entrada podem transformar uma configuração pequena noutra tarefa. Isso não exige substituir antecipadamente uma solução que funciona, mas justifica considerar estas possibilidades antes de fixar a topologia.

VPN site-to-site tradicional: As gateways tratam da ligação

Duas firewalls ou routers estabelecem um túnel cifrado, frequentemente com IPsec ou WireGuard configurado manualmente. O encaminhamento local envia para o túnel o tráfego destinado à rede remota. A outra gateway decifra os pacotes e encaminha-os para a rede de destino.

Com três locais, a sede pode funcionar como concentrador. Filial e laboratório ligam-se a ela. Simplifica a estrutura, mas os seus intercâmbios passam pela sede. Uma malha completa liga diretamente cada par. Com n locais, são n × (n − 1) / 2 ligações: três para três locais, já 45 para dez. Controladores e mecanismos dinâmicos reduzem o trabalho; as VPN tradicionais não se limitam a estrelas configuradas à mão.

Vantagens: integra-se nas firewalls existentes e em limites claros entre locais. Controlamos os extremos do túnel. Não existe outro fornecedor de malha no percurso dos dados; regras, rotas e registos enquadram-se na administração atual.

Desvantagens: rotas, chaves e operação exigem mais trabalho com o aumento das instalações. NAT, endereços variáveis e fabricantes distintos dificultam o diagnóstico. Utilizadores móveis precisam frequentemente de acesso remoto separado.

Um IP público fixo em cada local não é um requisito universal. Muitas vezes basta um concentrador acessível e túneis de saída nas filiais. DNS dinâmico e travessia de NAT também ajudam. Com CGNAT restritivo em ambos os lados, porém, uma ligação direta torna-se difícil sem endpoint acessível ou intermediário.

Para duas instalações estáveis com firewalls adequadas continua a ser uma escolha sensata. Não substituiria uma VPN funcional apenas porque outro produto apresenta menos campos de configuração.

Tailscale: Ligações diretas e coordenação central

Tailscale acrescenta ao WireGuard registo de dispositivos, coordenação e políticas de acesso. O serviço de controlo ajuda os participantes a encontrarem-se. Os dados seguem diretamente entre pares quando possível. Se NAT ou firewall impedirem isso, um relay fornece outro caminho. Mesmo através de DERP, o tráfego mantém-se cifrado entre os pares Tailscale.

Os routers de sub-rede ligam LAN completas ao tailnet. O cenário site-to-site documentado utiliza Linux nos dois extremos. Os dispositivos atrás deles não precisam de agente, mas necessitam de rotas corretas. Desativar o NAT de origem para conservar os endereços originais torna especialmente importante planear o retorno.

Vantagens: dispositivos LAN existentes participam através de routers de sub-rede. Ligações diretas evitam o desvio obrigatório por um local central. A mesma plataforma aceita dispositivos individuais adicionais.

Desvantagens: o caminho direto não é garantido. Relays podem alterar latência e débito. A coordenação alojada continua a ser uma dependência operacional; plano e funções devem adequar-se à instalação.

A cifra WireGuard termina no par participante. Sendo este um router de sub-rede, o segmento LAN seguinte fica fora do túnel. HTTPS e SSH continuam úteis na rede privada.

NetBird: Malha semelhante, com alojamento próprio

NetBird também usa WireGuard, tenta ligações diretas e recorre a relays quando necessário. Os routing peers ligam redes cujos equipamentos não executam o cliente. O guia site-to-site atual descreve Networks, Resources e respetivas políticas de acesso.

Vantagens: o projeto de código aberto oferece uma alternativa de alojamento próprio ao serviço cloud. Interessa quando infraestrutura e gestão devem continuar sob a nossa responsabilidade. Grupos e políticas permitem restringir os acessos deliberadamente.

Desvantagens: alojar significa cuidar de atualizações, cópias, monitorização e disponibilidade da coordenação e dos relays. Uma instalação rápida não elimina essas tarefas. O cenário documentado com Networks mantém o masquerading ativo, pelo que o destino não vê simplesmente o endereço de origem original. Outras variantes de encaminhamento exigem planeamento próprio.

Tailscale e NetBird são próximos, mas as configurações não são intercambiáveis. Avaliaria ambos segundo o encaminhamento e o modelo de identidade necessários. Código aberto também não significa utilização irrestrita de todas as funções: é preciso verificar licenças e capacidades para a instalação prevista.

Cloudflare Mesh: O caminho passa pela rede do fornecedor

Os participantes estabelecem ligações de saída para Cloudflare. O tráfego entre instalações atravessa a sua rede. Não é preciso ligar diretamente cada local a todos os outros nem gerir um concentrador VPN próprio. O limite de confiança e o percurso diferem, contudo, de uma malha WireGuard direta.

Vantagens: reúne conectividade e políticas Gateway centrais. Pode ser especialmente adequado onde Cloudflare One já é utilizado. Instalações atrás de NAT e clientes móveis aderem por ligações de saída.

Desvantagens: operação e caminhos dependem do fornecedor. O tratamento deve satisfazer os requisitos de confiança e privacidade para dados sensíveis. TLS e SSH continuam úteis para a aplicação. O benefício do percurso tem de ser medido; um backbone global não garante melhor desempenho em todo o lado.

Numa instalação nova seguiria o cliente atualmente documentado. Cloudflare identifica Mesh como beta e exige MASQUE no perfil dos nós. Com WireGuard documenta limitações na alta disponibilidade e nas rotas IPv6 e por nome de host. Um router suportar WireGuard não basta para o considerar um nó Mesh equivalente.

Mesh também deve ser distinguido de um túnel cloudflared para aplicações específicas. Aqui trata-se de conectividade IP privada bidirecional entre participantes e redes encaminhadas.

As diferenças de relance

São estas as diferenças que pondero primeiro. O plano necessário e o percurso real precisam de verificação no ambiente concreto.

O que espero de uma interligação segura

Quando perguntam qual é a opção mais segura, começo pelas ligações permitidas e pela gestão de acesso. Um túnel cifrado pode permitir demasiado. Quero definir que redes alcançam que serviços, como proteger administradores e como revogar acessos. MFA na administração e para utilizadores inscritos pessoalmente, permissões limitadas e gateways mantidas entram nessa avaliação.

Os limites da cifra também variam. A VPN termina nas gateways; Tailscale e NetBird cifram entre pares, eventualmente routers de sub-rede. A LAN seguinte não fica automaticamente cifrada. Com Cloudflare, o tratamento na rede do fornecedor também deve respeitar as necessidades empresariais. HTTPS ou SSH continuam úteis para a aplicação.

Uma ligação de saída pode simplificar a instalação e evitar um serviço VPN público na filial. Não substitui uma política de acesso. Um IP público, por sua vez, não torna automaticamente uma firewall insegura. Contam os serviços expostos, a proteção e a operação. Não estabeleço uma classificação de segurança pelo nome do produto.

O que quero verificar antes da aceitação

Ida e volta precisam de funcionar. A rota para 10.2.0.0/24 pertence ao router ou cliente responsável. Se o destino responder por outra gateway predefinida, é necessária uma rota de retorno adequada. SNAT simplifica respostas, mas muda o endereço visível e afeta registos e regras. Deve ser uma escolha consciente.

Dois nós da rede sobreposta não bastam para alta disponibilidade. Após uma falha, os dispositivos LAN têm de alcançar a gateway seguinte. Keepalived e VRRP podem fornecer um endereço virtual. As rotas remotas também têm de escolher um nó saudável. Quero observar sessões TCP novas e existentes quando falha uma gateway ou túnel. Um processo ativo e um ping bem-sucedido respondem apenas parcialmente.

Os testes devem incluir ligações intencionalmente bloqueadas. Se SSH deve funcionar e outra aplicação ser recusada, é isso que precisa de ser verificado. ICMP não prova o funcionamento de uma regra TCP. Registo, políticas e firewall do destino devem corresponder.

Restam detalhes menos visíveis que determinam a utilização diária: prefixos únicos, resolução de nomes internos e MTU adequada. Nem 192.168.x.x nem 10.x.x.x garante ausência de conflitos. Pings pequenos funcionarem enquanto transferências grandes bloqueiam não me permite considerar a ligação concluída.

Uma comparação de desempenho exige a mesma transferência e aplicação interativa nas ligações reais. É preciso registar o caminho direto ou por relay, a carga CPU e o comportamento após mudar de acesso. A minha avaliação trata de arquitetura e operação; não constitui uma classificação de velocidade medida destes produtos.

Acesso remoto: Acrescentar dispositivos individuais

Um colaborador que liga o portátil de casa à rede empresarial utiliza acesso remoto ou client-to-site. O cliente corre no portátil e não liga automaticamente toda a rede doméstica à sede. Pode utilizar-se o serviço da firewall central ou os clientes das plataformas comparadas. O registo pessoal permite associar permissões a utilizadores e grupos.

Um escritório doméstico também pode ser um local site-to-site: uma gateway liga uma rede autorizada ou VLAN à sede. A distinção é entre ligar um dispositivo ou uma rede, não entre trabalhar em casa ou numa filial. Para equipamentos individuais, o acesso remoto costuma ter o âmbito adequado. Não há motivo para tornar toda a rede privada acessível sem essa intenção.

Onde cada abordagem faz sentido para mim

Para poucas instalações fixas com firewalls existentes, começaria pela VPN tradicional, escolhendo conscientemente estrela ou túneis diretos. Para locais atrás de NAT com gestão central e caminhos diretos quando possível, compararia Tailscale e NetBird. Se operar a coordenação for obrigatório, NetBird entra cedo na avaliação. Onde já existem políticas Cloudflare One, examinaria Mesh, o estado beta e o tratamento no fornecedor. O acesso remoto adicional é um critério separado.

Headscale é outra hipótese: uma implementação própria do servidor de coordenação Tailscale. É um projeto separado com capacidades próprias, não um substituto integral de todas as funções alojadas. WireGuard manual já pertence ao modelo tradicional e faz sentido se bastarem poucos túneis sem outra camada de gestão.

Quando me perguntam pela melhor solução, quero recomendar algo adequado à empresa e às próximas mudanças. Uma instalação pequena com firewalls existentes pode continuar bem servida por VPN tradicional. Outras condições de acesso ou necessidades de gestão justificam avaliar malhas. Decidiria pela possibilidade de operar com segurança, compreender e restabelecer após falhas as ligações necessárias.

Até à próxima,
Joe