ddclient publica la salida VPN: corrige la fuente de descubrimiento

Tu nombre DNS ahora resuelve a una dirección de un proveedor VPN, y el registro de actualizaciones parece perfectamente sano. Esa combinación es normal. Una sonda de descubrimiento basada en web pregunta a un servicio externo qué origen ve, y cuando la petición sale por un túnel VPN completo, la respuesta es la salida VPN y no tu dirección WAN doméstica. El actualizador hizo su trabajo; el trabajo apuntaba a una observación equivocada.

Confirma a qué debe llegar el nombre

Un nombre público para un servicio doméstico de entrada necesita una dirección por la que las conexiones entrantes aprobadas puedan llegar a ese servicio. Publicar una salida compartida del proveedor no organiza allí ningún reenvío entrante, y ninguna cantidad de configuración DNS crea ese reenvío. Decide esto antes de tocar el actualizador, porque determina qué dirección es la correcta.

Un nombre privado para la dirección del túnel de un cliente VPN es otro problema con otra respuesta: pertenece al DNS privado y no necesita ningún servicio público de descubrimiento. Mezclar los dos requisitos es como una configuración que funciona empieza a publicar una dirección que nadie pidió.

Las direcciones de interfaz también necesitan interpretación. La dirección de un portátil tras un router doméstico no es la dirección WAN pública, e incluso la dirección WAN del router puede estar tras NAT de operador, donde publicarla no puede producir accesibilidad entrante.

Reproduce el valor antes de cambiar nada

Observa las dos rutas por separado. Con el túnel activo, una sonda informa de la salida; con el túnel inactivo, o con la sonda ligada a la interfaz física, informa de la dirección doméstica: curl --interface eth0 https://ifconfig.me. Si esas dos respuestas difieren, has reproducido el fallo sin tocar el actualizador.

Después ejecuta el cliente en un modo que compruebe la configuración sin realizar una actualización, como ddclient -verbose -noexec, y lee qué método de descubrimiento eligió. La salida detallada nombra el método y el valor obtenido, y ese es el dato que necesitas antes de editar nada.

Dirige el descubrimiento a la ruta elegida

Si el nombre debe publicar la dirección WAN doméstica, el descubrimiento tiene que observar esa dirección. Funcionan tres opciones, en orden aproximado de preferencia: deja que el router publique mediante su propio actualizador compatible; usa el descubrimiento de estado del router de ddclient contra una página que el router sirva de verdad; o mantén una sonda web pero ligada a la interfaz física para que salga fuera del túnel.

Para la ruta de estado del router, las versiones recientes de ddclient usan la familia de opciones usev4 y fwv4, con un patrón de omisión opcional para el texto que rodea la página. Consulta el README de tu versión instalada, porque las versiones antiguas escriben la misma idea con use y fw, y un nombre de opción copiado de la versión equivocada falla al arrancar.

Si mantienes el descubrimiento web, recuerda que enrutar la sonda y enrutar la llamada a la API de actualización son decisiones separadas. La llamada de actualización entrega el registro; la sonda decide el valor que se entrega.

Mantén secretos y versiones en orden

Las credenciales del router y los tokens del proveedor van en un archivo de configuración protegido, no en una línea de comandos que acabe en el historial del shell. Los rastros detallados pueden contener ambos, así que redáctalos antes de pegarlos en un tique. Un método de descubrimiento que exige extraer una página autenticada del router también exige que mantengas esa credencial funcionando entre actualizaciones de firmware. Guárdala con el mismo cuidado que el token del proveedor.

El ddclient README documenta los enfoques de descubrimiento y sus nombres de opción. No mezcles resultados de IPv4 e IPv6 en un solo registro, y no des por hecho que una opción presente en una versión existe en otra.

Verifica el valor y después la accesibilidad

Compara la dirección propuesta con el extremo previsto antes de permitir una actualización en vivo, luego comprueba el DNS autoritativo tras una actualización autorizada y cuenta con las cachés de los resolutores. Un TTL bajo acorta la espera; no hace buena una dirección equivocada.

Solo cuando el registro sea correcto deberías probar el servicio entrante desde una red independiente, con el cortafuegos y el reenvío necesarios ya aprobados. Un registro A correcto no demuestra un servicio accesible, y un arrendamiento VPN estático puede simplificar el nombrado privado sin reparar un nombre de host público que apunta a la WAN equivocada.