Por que escolhemos o Tailscale para conectar duas operações rurais

Em Iguatemi, a operação dependia de uma conexão rural via rádio de baixa qualidade. Implantamos uma nova conexão via satélite como caminho principal e mantivemos o rádio apenas como contingência. Em Sidrolândia, a conexão via satélite era o caminho principal; com a chegada da fibra, ela passou a ser a principal e o enlace via satélite ficou como fallback.

As conexões disponíveis às duas unidades operavam atrás de CGNAT. Um endereço público contratado em apenas um dos caminhos não acompanharia toda a contingência. Em Sidrolândia, manter a fibra sob CGNAT evitou um custo adicional que não resolveria o desenho completo e não traria benefício operacional proporcional.

A Goalmoon também implantou uma nova arquitetura Ubiquiti para organizar as redes. Esse trabalho merece uma análise própria. Nesta matéria, o foco é a decisão tomada depois: como conectar as duas unidades sem transformar os servidores em pontos de VPN e sem abrir mão dos links de fallback.

Não houve uma competição formal entre marcas. Partimos de requisitos operacionais concretos e procuramos uma camada que pudesse ser instalada nos dois gateways UDM, anunciar as redes locais e continuar funcionando quando o caminho de internet mudasse.

Instalamos o Tailscale nos gateways e configuramos cada UDM como roteador de sub-rede. Assim, cada equipamento anuncia sua rede local para a malha segura e encaminha o tráfego autorizado. Os servidores permanecem atrás dos gateways, sem cliente Tailscale, mudança de endereço ou exposição direta à internet.

O Tailscale usa técnicas de travessia de NAT para tentar formar uma conexão direta entre os dispositivos. Quando isso não é possível, pode recorrer a um relay criptografado. No ambiente implantado, a comunicação começou pelo relay e depois estabeleceu conexão direta, mesmo com CGNAT nos dois lados.

Esse comportamento atendia ao ponto central do projeto: a conectividade entre as unidades deveria depender dos gateways e das rotas anunciadas, enquanto os servidores continuariam dedicados ao trabalho local para o qual foram instalados.

Primeiro validamos comunicação bidirecional entre as redes, acesso aos serviços autorizados e sessões de suporte remoto. Depois reiniciamos os gateways para conferir a persistência da instalação e das rotas.

Em Sidrolândia, provocamos a saída do link de fibra e confirmamos a entrada automática do enlace de contingência. Em seguida, validamos o retorno à fibra. Durante o ciclo de failover e failback, a rota entre as unidades permaneceu disponível. O mesmo princípio foi documentado para o par de links de Iguatemi.

Também produzimos documentação em três níveis: uma referência de engenharia, um procedimento para administração de usuários e um guia simples para quem precisa de acesso remoto. A solução técnica passou a ter um modo explícito de operação, suporte e revogação.

Um IP público não é, por si só, um problema ou uma vantagem. Neste caso, contratar esse recurso em apenas um dos caminhos não resolveria a continuidade entre provedores. A combinação de gateways, rotas de sub-rede e travessia de NAT entregou o resultado necessário sem criar uma despesa que não teria benefício real no desenho adotado.

A implantação nas UDMs usa uma integração comunitária e não um recurso nativo da interface UniFi. Por isso, reinicializações, atualizações do sistema e restaurações exigem procedimentos de verificação. Essa é uma responsabilidade operacional aceita, registrada e acompanhada.

O aprendizado maior foi separar as camadas sem isolá-las. A nova arquitetura de rede criou a base; a redundância dos links preservou caminhos alternativos; e o Tailscale acrescentou a interligação segura. Cada parte resolve um problema distinto e todas precisam ser testadas em conjunto.