ddclient publica a saída VPN: corrija a fonte de descoberta

O seu nome DNS agora resolve para um endereço de um provedor VPN, e o registo de atualização parece perfeitamente saudável. Essa combinação é normal. Uma sonda de descoberta baseada na web pergunta a um serviço externo que origem vê, e quando o pedido sai através de um túnel VPN completo, a resposta é a saída VPN e não o seu endereço WAN doméstico. O atualizador fez o seu trabalho; o trabalho apontava para uma observação errada.

Confirme a que o nome deve chegar

Um nome público para um serviço doméstico de entrada precisa de um endereço através do qual ligações de entrada aprovadas possam chegar a esse serviço. Publicar uma saída partilhada do provedor não organiza ali qualquer encaminhamento de entrada, e nenhuma configuração DNS cria esse encaminhamento. Decida isto antes de tocar no atualizador, porque determina qual endereço está correto.

Um nome privado para o endereço do túnel de um cliente VPN é outro problema com outra resposta: pertence ao DNS privado e não precisa de todo de um serviço público de descoberta. Misturar os dois requisitos é como uma configuração funcional começa a publicar um endereço que ninguém pediu.

Os endereços de interface também necessitam de interpretação. O endereço de um portátil atrás de um router doméstico não é o endereço WAN público, e até o endereço WAN do router pode estar atrás de NAT de operador, onde publicá-lo não pode produzir acessibilidade de entrada.

Reproduza o valor antes de alterar qualquer coisa

Observe os dois caminhos em separado. Com o túnel ativo, uma sonda relata a saída; com o túnel desligado, ou com a sonda ligada à interface física, relata o endereço de casa: curl --interface eth0 https://ifconfig.me. Se essas duas respostas diferirem, reproduziu a falha sem tocar no atualizador.

Depois execute o cliente num modo que verifica a configuração sem realizar uma atualização, como ddclient -verbose -noexec, e leia qual método de descoberta escolheu. A saída detalhada nomeia o método e o valor obtido, e esse é o facto de que precisa antes de editar qualquer coisa.

Direcione a descoberta para o caminho escolhido

Se o nome tiver de publicar o endereço WAN doméstico, a descoberta tem de observar esse endereço. Funcionam três opções, por ordem aproximada de preferência: deixe o router publicar através do seu próprio atualizador suportado; use a descoberta de estado do router do ddclient contra uma página que o router sirva de facto; ou mantenha uma sonda web mas ligue-a à interface física para que saia fora do túnel.

Para o caminho do estado do router, as versões recentes do ddclient usam a família de opções usev4 e fwv4, com um padrão de salto opcional para o texto em volta da página. Consulte o README da sua versão instalada, porque as versões antigas escrevem a mesma ideia com use e fw, e um nome de opção copiado da versão errada falha no arranque.

Se mantiver a descoberta web, lembre-se de que encaminhar a sonda e encaminhar a chamada à API de atualização são decisões separadas. A chamada de atualização entrega o registo; a sonda decide o valor que é entregue.

Mantenha segredos e versões em ordem

As credenciais do router e os tokens do provedor pertencem a um ficheiro de configuração protegido, não a uma linha de comandos que acabe no histórico da shell. Os rastos detalhados podem conter ambos, por isso redija-os antes de os colar num ticket. Um método de descoberta que exige extrair uma página autenticada do router também exige que mantenha essa credencial a funcionar entre atualizações de firmware. Guarde-a com o mesmo cuidado do token do provedor.

O ddclient README documenta as abordagens de descoberta e os nomes das suas opções. Não misture resultados de IPv4 e IPv6 num só registo, e não assuma que uma opção presente numa versão existe noutra.

Verifique o valor e depois a acessibilidade

Compare o endereço proposto com o endpoint pretendido antes de permitir uma atualização em direto, depois verifique o DNS autoritativo após uma atualização autorizada e conte com as caches dos resolvedores. Um TTL baixo encurta a espera; não torna correto um valor errado.

Só quando o registo estiver correto deve testar o serviço de entrada a partir de uma rede independente, com a firewall e o encaminhamento necessários já aprovados. Um registo A correto não prova um serviço acessível, e um arrendamento VPN estático pode simplificar a nomenclatura privada sem reparar um nome de anfitrião público que aponta para a WAN errada.