ddclient publica a saída VPN: corrixe a fonte de descuberta

O teu nome DNS agora resolve a un enderezo dun provedor VPN, e o rexistro de actualizacións parece perfectamente san. Esa combinación é normal. Unha sonda de descuberta baseada na web pregunta a un servizo externo que orixe ve, e cando a petición sae por un túnel VPN completo, a resposta é a saída VPN e non o teu enderezo WAN doméstico. O actualizador fixo o seu traballo; o traballo apuntaba a unha observación errónea.

Confirma a que debe chegar o nome

Un nome público para un servizo doméstico de entrada necesita un enderezo polo que as conexións entrantes aprobadas poidan chegar a ese servizo. Publicar unha saída compartida do provedor non organiza alí ningún reenvío entrante, e ningunha cantidade de configuración DNS crea ese reenvío. Decide isto antes de tocar o actualizador, porque determina que enderezo é o correcto.

Un nome privado para o enderezo do túnel dun cliente VPN é outro problema con outra resposta: pertence ao DNS privado e non necesita ningún servizo público de descuberta. Mesturar os dous requisitos é como unha configuración que funciona comeza a publicar un enderezo que ninguén pediu.

Os enderezos de interface tamén necesitan interpretación. O enderezo dun portátil tras un router doméstico non é o enderezo WAN público, e mesmo o enderezo WAN do router pode estar tras NAT de operador, onde publicalo non pode producir accesibilidade entrante.

Reproduce o valor antes de cambiar nada

Observa as dúas rutas por separado. Co túnel activo, unha sonda informa da saída; co túnel inactivo, ou coa sonda ligada á interface física, informa do enderezo da casa: curl --interface eth0 https://ifconfig.me. Se esas dúas respostas difiren, reproduciches o fallo sen tocar o actualizador.

Despois executa o cliente nun modo que comprobe a configuración sen realizar unha actualización, como ddclient -verbose -noexec, e le o método de descuberta que escolleu. A saída detallada nomea o método e o valor obtido, e ese é o dato que necesitas antes de editar nada.

Dirixe a descuberta á ruta escollida

Se o nome debe publicar o enderezo WAN doméstico, a descuberta ten que observar ese enderezo. Funcionan tres opcións, en orde aproximada de preferencia: deixa que o router publique mediante o seu propio actualizador compatible; usa a descuberta de estado do router de ddclient contra unha páxina que o router sirva de verdade; ou mantén unha sonda web pero ligada á interface física para que saia fóra do túnel.

Para a ruta de estado do router, as versións recentes de ddclient usan a familia de opcións usev4 e fwv4, cun patrón de omisión opcional para o texto que rodea a páxina. Consulta o README da túa versión instalada, porque as versións antigas escriben a mesma idea con use e fw, e un nome de opción copiado da versión equivocada falla ao arrincar.

Se mantés a descuberta web, lembra que encamiñar a sonda e encamiñar a chamada á API de actualización son decisións separadas. A chamada de actualización entrega o rexistro; a sonda decide o valor que se entrega.

Mantén secretos e versións en orde

As credenciais do router e os tokens do provedor van nun ficheiro de configuración protexido, non nunha liña de comandos que acabe no historial do shell. Os rastros detallados poden conter ambos, así que redáctalos antes de pegarlos nun ticket. Un método de descuberta que exixe extraer unha páxina autenticada do router tamén exixe que manteñas esa credencial funcionando entre actualizacións de firmware. Gárdaa co mesmo coidado que o token do provedor.

O ddclient README documenta os enfoques de descuberta e os seus nomes de opción. Non mestures resultados de IPv4 e IPv6 nun só rexistro, e non deas por feito que unha opción presente nunha versión existe noutra.

Verifica o valor e despois a accesibilidade

Compara o enderezo proposto co punto final previsto antes de permitir unha actualización en vivo, despois comproba o DNS autoritativo tras unha actualización autorizada e conta coas cachés dos resolutores. Un TTL baixo acurta a espera; non fai boa un enderezo equivocado.

Só cando o rexistro sexa correcto deberías probar o servizo entrante desde unha rede independente, coa devasa e o reenvío necesarios xa aprobados. Un rexistro A correcto non demostra un servizo accesible, e un arrendamento VPN estático pode simplificar o nomeado privado sen reparar un nome de host público que apunta á WAN equivocada.