Você precisa de DNS dinâmico para um servidor VPN doméstico?

A maioria das falhas de VPN doméstica que me perguntam não são falhas de DNS, e ainda assim as pessoas compram primeiro uma assinatura de DNS dinâmico. Antes de configurar qualquer coisa, decida se o nome de host é a parte que está realmente quebrada. Um atualizador reescreve um registro quando o endereço que o provedor lhe deu se move; ele não pode abrir uma porta, atravessar o NAT da operadora nem fazer uma sessão WireGuard ativa perceber que o endpoint mudou. Três condições decidem se o DNS dinâmico é toda a solução ou apenas uma linha dela.

Condição um: o seu endereço se move de verdade

Endereços residenciais se movem por motivos banais: o modem ressincroniza após queda de energia, o provedor reequilibra um pool, um novo lease chega após uma queda longa. Em algumas linhas eles também se movem raramente, e já vi o mesmo endereço durar um ano; planos empresariais costumam incluir um fixo. Se nada mudou em doze meses, um único registro A editado à mão é um daemon a menos para manter vivo.

Meça em vez de adivinhar. Leia o endereço WAN na página de status do roteador e compare com o que o mundo externo vê. Execute isto de uma máquina na LAN:

curl -fsS https://api.ipify.org; echo

Se os dois valores diferirem, algo está traduzindo na frente do seu roteador e nenhuma atualização de nome de host corrige isso. Um endereço dentro de 100.64.0.0/10 é a faixa compartilhada para NAT de nível de operadora, e é o motivo habitual de um nome atualizado corretamente ainda expirar por tempo de fora.

Condição dois: os clientes voltam a resolver o nome

O TTL curto é a parte que as pessoas pulam. Resolvedores recursivos respeitam o TTL do registro, mas as pilhas dos clientes fazem cache separadamente, e um túnel já levantado não resolve nada de novo. Defina o registro em 60-300 segundos enquanto depura; isso encurta a janela em que uma resposta velha é servida e não migra uma sessão conectada.

OpenVPN resolve novamente a linha remote vpn.example.net 1194 a cada reconexão, e resolv-retry infinite o mantém tentando de novo em vez de sair quando a consulta falha. No servidor, float permite que uma sessão estabelecida siga um par cujo endereço de origem mudou. O WireGuard é mais direto: wg-quick up resolve o Endpoint quando a configuração é aplicada, e o cliente resolve de novo quando reconstrói o túnel, então um handshake que ainda funciona contra o endereço antigo continua funcionando até parar.

Essa diferença molda o plano. Se os clientes conectam sob demanda, uma mudança de endereço custa uma reconexão. Se mantêm uma sessão aberta por dias, espere que o túnel morra no próximo handshake, e faça o cliente tentar de novo em vez de supor que ele se mantém.

Condição três: o caminho de entrada ainda está aberto

O DNS dinâmico muda só para onde o nome aponta e nada mais. O encaminhamento de porta no roteador, a regra de firewall no host VPN e a permissão do provedor para pacotes de entrada precisam todos existir antes de o registro importar. Observe para onde o encaminhamento aponta: se está preso a um endereço WAN em vez da interface, uma mudança de endereço quebra o encaminhamento em silêncio e o registro leva a culpa.

Teste de fora. Um telefone em dados móveis com o Wi-Fi desligado é o teste honesto mais barato; um notebook na mesma LAN não é. Quando o nome resolve para o seu endereço público e o roteador não tem loopback NAT, um teste interno falha enquanto o registro está perfeitamente correto, e isso manda a maioria editar um registro que nunca esteve errado.

O que executar quando as três valem

ddclient é o atualizador que menos surpreende para um host pequeno. Uma configuração mínima publica o endereço que o provedor vê, o que evita o erro do NAT duplo:

protocol=dyndns2
use=web, web=https://api.ipify.org
server=updates.your-dns-provider.net
login=vpn-home
password=update-token
vpn.example.net

Execute-o de um timer systemd a cada poucos minutos em vez de um laço shell, e registre a resposta do provedor em vez de supor sucesso. Trate a credencial como uma chave, porque ela decide para onde cada cliente vai: use um token de atualização restrito em vez de senha da conta, mantenha o arquivo em modo 0600 e envie as atualizações por HTTPS.

Verifique antes de se comprometer

Uma consulta diz o que o resto do mundo vê, e imprime o TTL que você precisa aguardar após uma mudança:

dig +noall +answer vpn.example.net @1.1.1.1

Compare esse endereço com o endereço WAN do roteador. Se coincidirem, o nome faz o seu trabalho e o que ainda falha é alcançabilidade de entrada, uma chave ou um cliente que não resolveu de novo. Se diferirem, o atualizador publica a interface errada, muitas vezes porque rodava no host VPN atrás do roteador em vez de no próprio roteador.

Tenha um rollback de um minuto: anote o último endereço que funcionou e o TTL anterior, para poder publicar ambos à mão enquanto o provedor passa por uma tarde ruim.

Quando a resposta é não

Se a condição um ou três falhar, muda a decisão e não a configuração. Atrás do NAT da operadora, as opções práticas são pedir um endereço público ao provedor, mover o ponto de entrada para um VPS pequeno com endereço estável, ou usar uma camada sobreposta que mantém o seu próprio encontro. Se o endereço é fixo, pule o atualizador: um registro A, um registro AAAA se você usa IPv6, o mesmo encaminhamento de porta.

Se o endereço muda enquanto os clientes permanecem conectados, a correção honesta mora no cliente: lógica de reconexão e intervalo de nova tentativa, não um atualizador mais rápido. Um segundo provedor só esconde o intervalo.

Antes de seguir, confirme quatro coisas em ordem:

• O endereço que o atualizador publica coincide com o endereço WAN do roteador.
• O TTL do registro é curto o bastante para que uma mudança apareça em minutos.
• O encaminhamento de porta está ligado à interface, não a um endereço fixo.
• Um cliente real reconectou e passou tráfego desde a última mudança.

Se as quatro valerem, deixe a configuração em paz; a próxima falha é uma chave ou uma regra de firewall, não um problema de nomes. Se alguma falhar, corrija aquela linha antes de acrescentar outra peça móvel. RFC 2136 descreve o próprio mecanismo de atualização, caso queira ver o que o daemon coloca no fio.