WireGuard Mesh Networking: como criar uma rede Zero Trust entre servidores e NAS com Tailscale e Netmaker

Guia prático para construir uma rede em malha Zero Trust entre servidores remotos e um NAS com WireGuard, com dois caminhos concretos: Tailscale (SaaS) e Netmaker (autoalojado).

Nov 6, 2026 0 6

WireGuard Mesh Networking: como criar uma rede Zero Trust entre servidores e NAS com Tailscale e Netmaker

Ligar dois servidores com uma VPN ponto a ponto baseada em WireGuard configura-se em poucos minutos. O problema começa quando o número de nós cresce para cinco, dez, vinte: servidores na nuvem espalhados por diferentes fornecedores, um NAS no local, alguns Raspberry Pi e os portáteis da equipa. Configurar manualmente cada par de peers transforma-se rapidamente num pesadelo de chaves públicas, endereços IP e ficheiros de configuração a atualizar à mão a cada alteração.

É aqui que entra o conceito de mesh networking (rede em malha): uma rede em que cada dispositivo pode comunicar diretamente com qualquer outro dispositivo autorizado, sem passar por um único ponto central, e em que o acesso não depende de "estar dentro do perímetro da empresa", mas de regras explícitas verificadas em cada ligação. Este segundo princípio tem um nome: Zero Trust. Neste guia veremos como construir, na prática, uma malha Zero Trust entre servidores remotos e um NAS, usando o WireGuard como base criptográfica e duas ferramentas que o orquestram de forma muito diferente: Tailscale (serviço SaaS) e Netmaker (autoalojado).

WireGuard em poucas palavras: por que se tornou o padrão

O WireGuard é um protocolo VPN moderno, pensado para ser fácil de auditar (o seu código-fonte é ordens de grandeza menor do que o do OpenVPN ou do IPsec) e rápido, já que corre diretamente dentro do kernel do Linux desde a versão 5.6. Usa algoritmos criptográficos modernos como o Curve25519 para a troca de chaves e o ChaCha20 para a cifragem do tráfego, e identifica cada dispositivo através de um par de chaves pública/privada, em vez de nome de utilizador e palavra-passe.

O limite do WireGuard "puro" não é a segurança, mas a organização: por padrão, foi pensado para ligações ponto a ponto. Construir uma malha com muitos nós implica gerar e distribuir manualmente as chaves de cada peer a todos os outros, atualizar os endereços AllowedIPs a cada alteração e acompanhar tudo à mão. É exatamente isso que o Tailscale e o Netmaker automatizam: ambos usam o protocolo WireGuard por baixo, mas acrescentam uma camada de orquestração automática (distribuição de chaves, descoberta de peers, regras de acesso) que o torna gerível mesmo com dezenas de nós.

O princípio Zero Trust aplicado à rede

O modelo tradicional de segurança de rede baseia-se num perímetro: se um dispositivo está "dentro" (no escritório, na VPN da empresa), confia-se nele quase por completo. O problema é que, uma vez ultrapassado esse perímetro - uma credencial roubada, um portátil comprometido -, um atacante tem via livre para se mover lateralmente entre os sistemas.

O princípio Zero Trust inverte essa abordagem: nenhum dispositivo ou utilizador é considerado automaticamente confiável, nem mesmo os que já estão "dentro" da rede. Cada ligação é autenticada e autorizada individualmente, seguindo o princípio do menor privilégio: um servidor de cópias de segurança deve conseguir alcançar apenas o NAS onde escreve, não a base de dados de produção nem o posto do administrador. Aplicado a uma malha WireGuard, isto traduz-se na prática em duas coisas: uma identidade forte para cada nó (a chave pública do WireGuard, única por dispositivo) e um sistema de regras (uma ACL, lista de controlo de acesso) que decide explicitamente quem pode falar com quem, em vez de deixar que "qualquer pessoa na rede" alcance tudo.

Tailscale e Netmaker: duas filosofias diferentes

Tanto o Tailscale como o Netmaker constroem uma malha WireGuard automatizada, mas partem de pressupostos opostos. O Tailscale é um serviço SaaS: o plano de controlo (autenticação, distribuição de chaves, interface de gestão) é gerido pelos servidores do próprio Tailscale, enquanto o tráfego entre dispositivos viaja diretamente ponto a ponto sempre que possível. O Netmaker, por sua vez, foi pensado para ser autoalojado: instala-se o plano de controlo (a Community Edition, gratuita e de código aberto) no próprio servidor, permanecendo-se proprietário de toda a infraestrutura, dados incluídos.

Esta diferença reflete-se também nos preços. O Tailscale tem um plano "Personal" gratuito para uso não comercial, até 6 utilizadores com dispositivos ilimitados; os planos para equipas começam em 8 dólares por utilizador por mês (plano Standard), até aos 18 dólares do plano Premium, pensado para organizações maiores. O Netmaker, por outro lado, oferece uma Community Edition gratuita e de código aberto sem limites declarados de dispositivos ou redes, com planos pagos (Team e Business) cobrados por ligação ativa, a partir de cerca de 2 dólares por ligação por mês, pensados para quem quer funcionalidades extra como failover automático ou gestão de utilizadores mais avançada.

Em termos práticos: se o objetivo é começar imediatamente sem gerir um servidor adicional, e não há problema em confiar o plano de controlo a um fornecedor externo, o Tailscale é a opção mais rápida. Se, pelo contrário, a prioridade é manter toda a infraestrutura - incluindo o servidor que decide "quem fala com quem" - sob controlo próprio, o Netmaker é a opção a considerar, ao custo de ter mais um servidor para gerir.

Primeira via: uma malha Zero Trust com Tailscale

O Tailscale instala-se em cada dispositivo que deve fazer parte da rede (servidores, portáteis, Raspberry Pi) através de um cliente leve. Depois de autenticados, os dispositivos obtêm um endereço IP virtual estável no intervalo privado 100.64.0.0/10 (o mesmo intervalo usado para CGNAT) e conseguem alcançar-se diretamente.

Expor um NAS sem instalar nada nele

Muitos NAS não suportam a instalação direta de um cliente Tailscale, ou prefere-se evitar tocar no sistema do fabricante. A solução é o padrão do subnet router (router de sub-rede): instala-se o Tailscale num dispositivo sempre ligado na mesma rede local que o NAS (por exemplo, um pequeno servidor Linux ou um Raspberry Pi), que funciona como "ponte" para expor toda a sub-rede à malha, sem que o próprio NAS precise de saber nada sobre WireGuard ou Tailscale.

No dispositivo-ponte, depois de ativar o reencaminhamento de IP a nível de sistema, inicia-se o cliente com:

tailscale up --advertise-routes=192.168.1.0/24

onde 192.168.1.0/24 é a sub-rede local onde está o NAS. Este passo por si só não é suficiente: a rota anunciada tem de ser aprovada por um administrador na consola web de gestão (secção "Machines", dispositivo com a etiqueta "Subnets"), a menos que já esteja coberta por uma regra autoApprovers no ficheiro de política. Só então os outros nós da malha, se estiverem configurados para aceitar rotas com tailscale set --accept-routes (comportamento automático no macOS, iOS, Android e Windows), conseguem alcançar o NAS no seu endereço IP local original, como se estivessem na mesma LAN.

Escrever as regras de acesso (ACLs/grants)

Por padrão, uma "tailnet" recém-criada (nome dado pelo Tailscale à sua rede privada) permite que todos os dispositivos se alcancem mutuamente: tudo é permitido exceto as regras explícitas. Para aplicar verdadeiramente o princípio Zero Trust é preciso inverter essa lógica, removendo a regra permissiva por padrão e escrevendo apenas as permissões necessárias no ficheiro de política, em formato JSON. A sintaxe moderna chama-se grants (preferida em relação ao formato mais antigo acls, embora ambos possam coexistir), e cada regra especifica uma origem, um destino e as portas permitidas:

{
  "hosts": {
    "backup-server": "100.64.0.10",
    "nas": "100.64.0.20"
  },
  "grants": [
    {
      "src": ["backup-server"],
      "dst": ["nas"],
      "ip": ["tcp:445", "tcp:22"]
    }
  ]
}

Neste exemplo, apenas o servidor de cópias de segurança pode alcançar o NAS, e apenas pelas portas SMB (445) e SSH (22): nenhum outro dispositivo da malha, nem mesmo um com acesso total a outros sistemas, lhe pode aceder. Para organizar as permissões em vários dispositivos, podem usar-se etiquetas (tags), atribuídas na secção tagOwners da política: uma etiqueta transfere a "propriedade" do dispositivo de uma conta humana individual para a própria etiqueta, de modo que o acesso deixa de depender de quem iniciou sessão originalmente nessa máquina. Um detalhe prático nada trivial: remover uma etiqueta de um dispositivo não é simples - muitas vezes é necessário remover o nó da rede e voltar a registá-lo do zero -, por isso vale a pena planear com cuidado o esquema de etiquetas antes de o pôr em produção.

Acesso SSH sem chaves para gerir

Uma vantagem prática de confiar na identidade do Tailscale para toda a rede é poder ativar o acesso SSH "sem chaves": ao ativá-lo num servidor com tailscale set --ssh, a autenticação SSH passa a basear-se na identidade da tailnet em vez de chaves que seria preciso gerar, distribuir e revogar manualmente. As regras sobre quem pode aceder por SSH, e com que utilizador do sistema, definem-se num bloco separado da política:

{
  "ssh": [
    {
      "action": "check",
      "src": ["group:sysadmin"],
      "dst": ["tag:server"],
      "users": ["deploy"]
    }
  ]
}

Com "action": "check", o acesso exige reautenticação periódica (o intervalo define-se com checkPeriod), útil nos servidores mais sensíveis; com "action": "accept", o acesso é concedido de imediato depois de verificada a identidade. Em ambos os casos, a configuração SSH do próprio sistema operativo continua a ter de autorizar esse utilizador específico.

Dois avisos práticos antes de passar à produção: as chaves dos nós expiram por padrão após 180 dias, o que pode desligar silenciosamente um subnet router ou um exit node caso não se desative a expiração nos dispositivos com um papel de infraestrutura permanente; e as alterações à política têm efeito imediato ao guardar, pelo que uma regra demasiado restritiva pode cortar a própria sessão SSH com que se está a trabalhar - convém sempre rever o diff das alterações antes de as confirmar.

Segunda via: uma malha autoalojada com Netmaker

Se a prioridade é manter o controlo total da infraestrutura, o Netmaker Community Edition permite instalar o próprio plano de controlo num servidor, sem depender de um fornecedor externo para decidir quem pode acessar o quê.

Requisitos e instalação

Para a Community Edition, o Netmaker requer um servidor Ubuntu 24.04 (pode ser uma VM, hardware físico ou até a mesma máquina onde correm os outros serviços), com um mínimo de 1 GB de RAM, 1 CPU e 2 GB de armazenamento para testes, mas pelo menos 2 GB de RAM e 2 CPUs para uso em produção. É necessário um endereço IP público estático e, idealmente, um nome de domínio com acesso à gestão de DNS, porque o painel, a API, o broker MQTT e as ferramentas de monitorização (Prometheus, Grafana) precisam cada um do seu próprio subdomínio público (ou de um wildcard como *.netmaker.exemplo.pt). É preciso abrir as portas 80/TCP e 443/TCP para os certificados e a interface web, e a porta 51821/UDP para o tráfego WireGuard do agente.

A instalação guiada da Community Edition resume-se a descarregar e executar o script oficial a partir do repositório GitHub do Netmaker:

curl -sfL https://raw.githubusercontent.com/gravitl/netmaker/master/scripts/nm-quick.sh -o /root/nm-quick.sh
chmod +x /root/nm-quick.sh
sudo /root/nm-quick.sh

O script configura automaticamente os certificados TLS (via Caddy), o broker MQTT usado para a comunicação com os clientes e o painel de administração. Um aviso útil para quem usa o Cloudflare como proxy DNS: é preciso desativar o proxy ("nuvem cinzenta" em vez de laranja) nos registos usados pelo Netmaker, caso contrário o tráfego MQTT é bloqueado de uma forma que o próprio Netmaker não consegue diagnosticar.

Criar a rede e adicionar nós

No primeiro acesso ao painel, cria-se uma conta de administrador e, em seguida, cria-se uma nova rede, escolhendo um intervalo de endereços privados que não se sobreponha a outras redes já em uso (para redes com menos de 254 máquinas, um bloco como 10.11.12.0/24 é mais do que suficiente). O servidor Netmaker junta-se automaticamente à rede como primeiro nó.

Para adicionar um servidor remoto ou o dispositivo-ponte para o NAS, gera-se no painel uma enrollment key (secção "Keys"), definindo quantas vezes pode ser usada e a que redes dá acesso. No novo host, depois de confirmar que o WireGuard e o systemd estão instalados, instala-se o netclient para o sistema operativo correspondente e regista-se o nó com:

netclient register -k  -s grpc.meudominio.pt -p 50051

Pouco depois o nó aparece no painel de administração, e pode verificar-se a conectividade com um simples ping ao seu endereço privado na malha a partir de outro nó já ligado. Para os nós adicionados mais tarde a uma rede já existente, pode usar-se em alternativa um token de registo dedicado, pensado precisamente para esse caso.

O Netmaker gere a segurança da malha através de ACLs a nível de rede (quais os nós, dentro da mesma rede virtual, autorizados a falar entre si) e etiquetas que podem ser atribuídas às chaves de enrolamento - um mecanismo diferente, mas conceptualmente próximo dos grants do Tailscale: também aqui o objetivo é evitar que "fazer parte da malha" equivalha automaticamente a "ter acesso a tudo".

Boas práticas de segurança, qualquer que seja a ferramenta escolhida

Independentemente da via escolhida, algumas precauções aplicam-se a ambas. Primeiro: desativar a expiração automática das chaves nos dispositivos com um papel de infraestrutura permanente, como o subnet router que expõe o NAS ou o próprio servidor Netmaker - uma chave que expira sem aviso num nó crítico significa uma interrupção de serviço silenciosa. Segundo: aplicar sempre o princípio do menor privilégio ao escrever as regras de acesso, concedendo a cada nó apenas as portas e os peers de que realmente necessita, e não "tudo o que é preciso mais um pouco por precaução" - que é exatamente o oposto do espírito Zero Trust. Terceiro: manter atualizados tanto o cliente WireGuard subjacente como o software de orquestração (Tailscale ou o netclient do Netmaker), já que ambos recebem periodicamente correções de segurança. Quarto, e muitas vezes subestimado: testar as regras de acesso antes de confiar nelas em produção, verificando não só que as ligações autorizadas funcionam, mas também que as não autorizadas são de facto bloqueadas.

Qual escolher?

Não existe uma resposta universal, mas há algumas indicações práticas. Para um homelab, uma equipa pequena ou quem queira começar de imediato sem administrar um servidor adicional, o Tailscale oferece o caminho mais rápido, um plano gratuito generoso para uso pessoal e uma gestão de políticas suficientemente granular para implementar um verdadeiro modelo Zero Trust. Para quem já gere a sua própria infraestrutura de servidores, tem requisitos de conformidade que exigem manter os dados e o plano de controlo no local, ou simplesmente prefere não depender de um fornecedor SaaS externo para algo tão crítico como o acesso à rede, o Netmaker Community Edition oferece as mesmas garantias de segurança baseadas em WireGuard, ao custo de mais um servidor para administrar e manter atualizado. Em ambos os casos, o resultado final é o mesmo: uma malha cifrada, rápida por se basear em WireGuard, e concebida segundo o princípio de que nenhuma ligação é concedida por padrão, mas apenas porque foi explicitamente autorizada.