Um plano de controlo para uma malha privada.

Compreenda o que é coordenado

O plano de controlo gere o registo de nós e distribui informação de rede. O tráfego de dados pode usar ligações diretas entre pares ou um relay, dependendo da conectividade. Executar o coordenador não significa que todos os pacotes passem por ele.

Torne a inscrição intencional

Proteja o API administrativo e utilize métodos de registo de curta duração ou com âmbito adequado. Remova dispositivos perdidos ou desativados. A capacidade de aderir à malha não deve implicar acesso a todos os serviços.

Revise ACLs e rotas

Aplique regras de privilégio mínimo entre utilizadores e nós. As rotas de sub-rede anunciadas e os nós de saída ampliam a rede alcançável e requerem aprovação explícita. Teste o tráfego negado com o mesmo cuidado que o tráfego permitido.

Guarde o material de recuperação

Faça backup da configuração, do estado e das chaves de acordo com o procedimento da versão suportada. Mantenha uma forma de administrar o VPS caso a malha falhe. Verifique a compatibilidade dos clientes e as notas de atualização antes de alterar o plano de controle.

Registo, encaminhamento e política são verificações separadas

O Headscale coordena clientes Tailscale compatíveis; conexões diretas e caminhos de relay DERP têm comportamento de rede diferente. Um roteador de sub-rede anuncia um intervalo, o servidor de controle o aprova e o cliente deve aceitar a rota. Habilite o encaminhamento no nó de roteamento e mantenha os intervalos anunciados estreitos. Uma rota aprovada ainda precisa de uma política de acesso limitando quem pode usar qual destino e porta.

• Verifique a lista de rotas do servidor de controlo
• Testar a partir de um dispositivo autorizado
• Repita o mesmo teste a partir de um dispositivo que deve ser negado

headscale nodes list-routes

Documentação oficial: Rotas Headscale

Não coloque o único caminho de recuperação dentro da malha

Mantenha uma segunda forma de aceder à consola do servidor ou uma via de administrador rigorosamente restrita. Teste o que acontece quando o coordenador, o relay ou o cliente não estão disponíveis. Preserve o estado e as chaves do plano de controlo de acordo com a versão instalada. Uma malha privada pode simplificar o acesso, mas não deve tornar-se uma dependência não documentada que impeça a sua própria reparação.

Corrija a identidade do plano de controlo e a via de recuperação

Escolha um nome HTTPS estável, uma versão suportada do Headscale e clientes Tailscale compatíveis. Leia o exemplo de configuração fornecido com essa versão exata; uma configuração copiada de uma versão diferente pode falhar a validação ou descrever silenciosamente uma política diferente. Persista a base de dados do plano de controlo e as chaves necessárias. Mantenha o API administrativo privado e conserve uma consola separada ou uma rota SSH restrita, para que perder a malha não torne o seu coordenador impossível de reparar.

• Use um certificado válido para o nome público do plano de controle.
• Mantenha as chaves de inscrição com vida curta e âmbito adequado.
• Trate o design do relay e o namespace DNS como escolhas explícitas.

Documentação oficial: Implementação do contentor Headscale

Registe um dispositivo antes de anunciar uma rede

Inicie o servidor seguindo as instruções upstream e registe um utilizador/dispositivo de teste através do método de inscrição documentado. Confirme que o dispositivo alcança o URL de controlo esperado e aparece com a identidade pretendida. Inspecione o estado do cliente e teste um serviço privado antes de adicionar rotas de nó de saída ou de sub-rede. Um caminho DERP pode preservar a conectividade onde um caminho direto não está disponível; não indica que o coordenador está a encaminhar todos os pacotes.

• Comece com um dispositivo e serviço que você possa remover com segurança.
• Verifique se o tráfego de peering é direto ou retransmitido.
• Proteja o relay e os endpoints de controlo de acordo com a implementação selecionada.

Documentação oficial: Referência de implementação do Headscale

Aprove o encaminhamento e a autorização de forma independente

Para acesso à sub-rede, habilite o encaminhamento no nó de roteamento, anuncie um intervalo estreito, aprove-o no servidor de controle e certifique-se de que o cliente de destino o aceite. Evite redes sobrepostas que tornem a rota de retorno ambígua. Uma rota aprovada não é uma política de acesso: defina quem pode se conectar a qual destino e porta, incluindo dispositivos convidados. Teste uma conexão permitida e uma conexão idêntica negada antes de estender a malha.

# Run on the control server; syntax follows the installed release:
headscale nodes list-routes
# Client-side inspection:
tailscale status

Documentação oficial: Sub-rede e rotas de saída do Headscale

Encontre a camada avariada antes de alterar a política

Se a inscrição falhar, inspecione DNS, HTTPS e o URL do servidor. Se o dispositivo se juntar mas uma sub-rede estiver inacessível, inspecione o anúncio, a aprovação, a aceitação de rotas pelo cliente, o encaminhamento e o caminho de retorno. Se apenas um serviço falhar, inspecione o seu endereço de bind, a firewall do host e a política da mesh. Preserve uma cópia de segurança consistente da base de dados/configuração e teste uma atualização de versão com um cliente descartável antes de alterar o único plano de controlo.