Seu próprio servidor de controle.
O mapa é a coisa que vale a pena guardar.

Existem três respostas honestas para "eu quero que minhas máquinas se alcancem em privado", e só uma delas é este guia. WireGuard puro é a menor: um módulo do kernel, um arquivo de configuração por peer, nenhum daemon além da interface, nada para manter atualizado além do sistema operacional. Se os seus dispositivos são servidores com endereços fixos e você consegue contá-los nos dedos de uma mão, pare por aqui e leia o guia de WireGuard em vez deste. Você vai acabar com menos software e uma lista mais curta de coisas que podem quebrar.

Tailscale é a maior: o mesmo WireGuard por baixo, mais um serviço de coordenação, travessia de NAT que funciona por trás de quase qualquer coisa, uma frota de relays em vários continentes, um console web, login único e um contrato de suporte. É um software genuinamente excelente, e o nível gratuito atende uma residência com folga. O preço não é em dinheiro — é que o mapa de cada dispositivo seu, e o registro de onde cada um se conecta, vive no banco de dados de uma empresa.

Headscale é a terceira resposta, e é mais restrita que as outras duas: uma reimplementação de código aberto do servidor de coordenação, operada por você, com quem o mesmo cliente oficial conversa. Você mantém a automação e a travessia de NAT; em troca, assume um pequeno serviço para operar, um conjunto parcial de recursos e atualizações que exigem leitura. Ninguém deveria fingir que isso é de graça. Isso compra exatamente uma coisa, e é a coisa com que este site se importa: mais ninguém guarda o mapa.

Mais uma coisa para decidir agora, e não depois, porque isso muda o que você instala: se essa rede é só sua, ou se outras pessoas vão entrar nela. Um tailnet de uma única pessoa pode ficar totalmente aberto internamente sem que nada de ruim aconteça. Um tailnet com um colega, um terceirizado ou um familiar precisa de regras de acesso escritas desde a primeira semana — etapa 05 — e precisa que os usuários sejam separados, em vez de todo mundo compartilhar um login. Decidir isso de antemão custa um parágrafo; fazer essa adaptação depois custa uma tarde inteira.

Headscale e Caddy, e mais nada. O Headscale escuta em HTTP puro dentro da rede Docker; o Caddy termina o TLS, obtém o certificado na primeira inicialização e o renova sem que ninguém precise pedir. O listener de métricas fica em localhost, porque é uma superfície de depuração interna, não pública.

Uma regra antes do arquivo: fixe a imagem em uma versão exata. O Headscale é um software pré-1.0 que já renomeou chaves de configuração e subcomandos da CLI entre versões menores mais de uma vez. Uma tag flutuante transforma um restart de rotina do container em uma indisponibilidade de um serviço cuja função é justamente deixar você alcançar tudo o mais.

/srv/headscale/docker-compose.yml

services:
  headscale:
    image: docker.io/headscale/headscale:0.26            # pin it; never :latest
    container_name: headscale
    command: serve
    volumes:
      - ./config:/etc/headscale
      - ./data:/var/lib/headscale
    ports:
      - "3478:3478/udp"                                  # STUN, for your own DERP
    restart: unless-stopped

  caddy:
    image: caddy:2-alpine
    container_name: caddy
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile:ro
      - caddy_data:/data
    restart: unless-stopped

volumes:
  caddy_data:

/srv/headscale/Caddyfile

vpn.example.com {
    reverse_proxy headscale:8080
}

Essa é toda a configuração do proxy. O Caddy fala HTTP/2 e faz upgrade de conexões de longa duração sem que ninguém precise pedir, o que importa aqui porque todo cliente mantém uma aberta para receber atualizações do mapa. Pegue o arquivo de configuração de exemplo que acompanha a versão que você fixou e edite-o, em vez de escrever um do zero — o arquivo é longo, a maior parte dele são valores padrão sensatos, e as chaves que importam são estas:

/srv/headscale/config/config.yaml — the lines that matter

server_url: https://vpn.example.com          # exactly what clients will dial
listen_addr: 0.0.0.0:8080                    # inside the Docker network only
metrics_listen_addr: 127.0.0.1:9090          # debug surface, keep it local

prefixes:
  v4: 100.64.0.0/10
  v6: fd7a:115c:a1e0::/48

noise:
  private_key_path: /var/lib/headscale/noise_private.key

database:
  type: sqlite                               # postgres for a large fleet
  sqlite:
    path: /var/lib/headscale/db.sqlite

dns:
  magic_dns: true
  base_domain: ts.example.com                # NOT a parent or child of server_url
  nameservers:
    global:
      - 1.1.1.1                              # replaced by your own in step 05

Suba o serviço e leia o log, em vez de presumir. Uma primeira inicialização que não consegue obter um certificado, ou que rejeita o sufixo de DNS porque ele se sobrepõe ao hostname do servidor, avisa isso claramente e para.

docker compose up -d
docker compose logs -f headscale

# From your laptop — a control server that is up answers this:
curl -s https://vpn.example.com/health

A primeira inicialização gera o material da chave privada em /srv/headscale/data. Copie-o para um lugar seguro agora, antes que um único dispositivo se registre, e de novo depois da primeira inscrição: perder essa chave significa que todo dispositivo rejeita o servidor em quem confiava, e o único reparo é reinscrever todos eles manualmente. A etapa 06 transforma essa cópia em um backup de verdade.

Um tailnet em que todo dispositivo alcança todos os outros já é útil. Três acréscimos o transformam de um conjunto de túneis em uma rede de verdade, e os três compartilham uma característica que costuma confundir as pessoas: o cliente anuncia uma capacidade, e o servidor precisa aprová-la. Uma rota que é anunciada mas não aprovada simplesmente não existe, silenciosamente, e o sintoma é conseguir dar ping no roteador, mas em nada que esteja atrás dele.

Um roteador de sub-rede — coloque uma LAN inteira no tailnet. Uma máquina em uma rede doméstica ou de escritório anuncia a faixa de endereços da rede; todo outro dispositivo passa então a alcançar as impressoras, o NAS e as interfaces de gerenciamento atrás dela sem precisar instalar mais nada ali. Ative o encaminhamento no kernel primeiro, ou os pacotes param no roteador sem nenhuma mensagem de erro.

# On the machine that sits inside the LAN:
echo 'net.ipv4.ip_forward = 1'          | sudo tee /etc/sysctl.d/99-ts.conf
echo 'net.ipv6.conf.all.forwarding = 1' | sudo tee -a /etc/sysctl.d/99-ts.conf
sudo sysctl -p /etc/sysctl.d/99-ts.conf

sudo tailscale up --login-server https://vpn.example.com \
  --advertise-routes=192.168.1.0/24 --accept-routes

# On the control server — approve it, or it does not exist.
# The subcommand moved between releases; check `hs nodes --help` first.
hs nodes list
hs nodes approve-routes --identifier 3 --routes 192.168.1.0/24

Um nó de saída — envie tudo para fora através do VPS. O mesmo mecanismo com uma rota mais ampla: um dispositivo que se anuncia como nó de saída se oferece para carregar toda a conexão de internet de outro dispositivo. Em uma rede não confiável de café ou hotel, é exatamente isso que você quer, e é a coisa mais próxima de uma VPN pessoal que existe neste guia.

# On the VPS that will do the exiting (forwarding must be on, as above):
sudo tailscale up --login-server https://vpn.example.com --advertise-exit-node

# Approve it on the control server, then on the laptop:
tailscale set --exit-node=100.64.0.1 --exit-node-allow-lan-access
tailscale set --exit-node=                    # turn it off again

Um nó de saída não é uma VPN comercial, e você não deve se vender essa ideia. O endereço é só seu e é estável, o que é excelente contra o Wi-Fi do café e inútil contra a correlação de longo prazo entre sites — essa troca está detalhada no guia principal. Note também que é possível rodar o nó de saída em um segundo VPS, mais barato, e manter o servidor de controle totalmente livre de tráfego encaminhado.

Regras de acesso — escreva-as antes que a segunda pessoa entre. A política padrão é permitir tudo, o que está certo para um tailnet de uma pessoa só e errado no instante em que mais alguém entra nele. A política é um pequeno documento HuJSON: grupos de usuários, tags para máquinas e uma lista de regras que dizem quais origens podem alcançar quais destinos em quais portas. Aponte a configuração para o arquivo, mantenha o arquivo sob controle de versão e recarregue após cada edição.

{
  "groups": {
    "group:admin":     ["alice"],
    "group:contractor":["bob"]
  },
  "tagOwners": {
    "tag:server": ["group:admin"],
    "tag:exit":   ["group:admin"]
  },
  "acls": [
    // Admins reach everything.
    { "action": "accept", "src": ["group:admin"], "dst": ["*:*"] },

    // The contractor reaches one machine, on two ports, and nothing else.
    { "action": "accept", "src": ["group:contractor"],
      "dst": ["tag:server:22,443"] }
  ],
  "autoApprovers": {
    "routes":   { "192.168.1.0/24": ["tag:server"] },
    "exitNode": ["tag:exit"]
  }
}

Duas observações sobre esse arquivo. A linguagem de política é do Tailscale, e o Headscale implementa um subconjunto grande e crescente dela, não tudo — verifique a documentação da sua versão antes de confiar em uma regra exótica. E onde a política mora também já mudou: versões mais antigas indicavam um caminho na configuração de nível superior, as mais novas a agrupam sob uma seção de política com um modo que também pode manter as regras no banco de dados. Ambas estão documentadas; a que importa é a que a sua versão fixada traz.

MagicDNS — nomes curtos, e o seu próprio resolvedor em todo lugar. Com o MagicDNS ativado, todo dispositivo responde por um nome curto dentro do sufixo que você escolheu na etapa 02, então ssh nas funciona de qualquer lugar sem precisar de um arquivo hosts. A segunda metade é a interessante: o servidor de controle também envia uma lista de servidores de nome para cada cliente, o que significa que o resolvedor que você construiu no guia de resolvedor de DNS privado pode atender o seu celular em dados móveis — filtrando, fazendo cache e sem registrar nada — enquanto escuta em um endereço do tailnet que não é alcançável pela internet de jeito nenhum.

dns:
  magic_dns: true
  base_domain: ts.example.com
  override_local_dns: true          # beat whatever DHCP handed the device
  nameservers:
    global:
      - 100.64.0.5                  # your resolver, on the tailnet

Auto-hospedar o plano de controle é uma melhoria real e específica, não um passe de mágica. Cinco coisas continuam verdadeiras depois que tudo acima está feito, e conhecê-las é a diferença entre uma defesa de verdade e uma história reconfortante.

O servidor de controle é um endpoint público e nomeado. Todo dispositivo disca para ele, então ele tem um hostname, e esse hostname é publicado em logs de certificate transparency no instante em que o certificado é emitido. Ele é descobrível mesmo que você nunca link para ele, e seu endereço é a única constante que todos os seus dispositivos têm em comum. Use um subdomínio de um nome que você já publica, em vez de um que descreva o que ele é.

O Headscale é uma reimplementação, e ele assume isso. Ele não é construído nem suportado pelo Tailscale, a paridade de recursos é parcial por construção, e parte do que o produto hospedado vende — o console web, a frota pública de relays, os fluxos refinados de login único — ou simplesmente não existe aqui, ou é um projeto de terceiros que ninguém auditou. Consulte a documentação do projeto para saber se um recurso existe antes de basear um plano nele, e trate as atualizações como uma tarefa, não como um processo em segundo plano.

Os relays padrão ainda são de outra pessoa. Até você ativar o servidor DERP embutido, uma conexão que não consegue ir direto recorre à frota pública de relays. O payload continua criptografado ponta a ponta e ninguém consegue lê-lo — mas o fato de que dois dos seus dispositivos estão conversando, e o quanto, transita por uma infraestrutura que não é sua. Essa é a parte da cadeia de confiança que a maioria das pessoas não percebe na primeira tarde.

Um nó de saída é um endereço estável, não uma multidão. Rotear o seu tráfego através do seu próprio VPS derrota a rede do café e o perfil montado pelo provedor de internet. Não derrota a correlação, porque esse endereço pertence só a você e não muda. O endereço compartilhado de uma VPN comercial é pior em todos os aspectos, exceto no único que importa para essa ameaça específica.

A máquina ainda está dentro de um prédio. Um servidor alugado roda em hardware dentro de um datacenter com portas e funcionários. O que muda é que não existe um índice, no nível do produto, dos seus dispositivos, nenhum banco de dados de empresa registrando de onde cada um se conecta, e nenhuma política de privacidade que possa ser alterada no próximo trimestre. O que não muda é que o disco é físico e não está dentro da sua casa.

O que você comprou de verdade, com precisão: a lista de cada máquina sua, o registro de onde cada uma se conecta, e a autoridade para adicionar uma nova, ficam todos guardados em uma máquina que você aluga sem nome nenhum atrás dela. Essa é uma afirmação restrita, e é uma afirmação real. Ela só vale o que custa se a etapa 06 estiver feita — um plano de controle auto-hospedado sem uma restauração testada não é uma melhoria de privacidade, é um ponto único de falha com uma marca melhor.