ddclient pubblica l'uscita VPN: correggi la fonte di scoperta

Il tuo nome DNS ora risolve su un indirizzo di un provider VPN, e il registro degli aggiornamenti sembra del tutto sano. Questa combinazione è normale. Una sonda di scoperta basata sul web chiede a un servizio esterno quale sorgente vede, e quando la richiesta esce attraverso un tunnel VPN completo, la risposta è l'uscita VPN e non il tuo indirizzo WAN domestico. L'aggiornatore ha fatto il suo lavoro; il lavoro era puntato sull'osservazione sbagliata.

Conferma a cosa deve arrivare il nome

Un nome pubblico per un servizio domestico in ingresso richiede un indirizzo attraverso cui le connessioni in ingresso approvate possano raggiungere quel servizio. Pubblicare un'uscita condivisa del provider non organizza lì alcun inoltro in ingresso, e nessuna configurazione DNS crea quell'inoltro. Decidilo prima di toccare l'aggiornatore, perché determina quale indirizzo è corretto.

Un nome privato per l'indirizzo del tunnel di un client VPN è un altro problema con un'altra risposta: appartiene al DNS privato e non ha affatto bisogno di un servizio di scoperta pubblico. Mescolare i due requisiti è il modo in cui una configurazione funzionante inizia a pubblicare un indirizzo che nessuno ha chiesto.

Anche gli indirizzi di interfaccia richiedono interpretazione. L'indirizzo di un portatile dietro un router domestico non è l'indirizzo WAN pubblico, e persino l'indirizzo WAN del router può trovarsi dietro NAT dell'operatore, dove pubblicarlo non può produrre raggiungibilità in ingresso.

Riproduci il valore prima di cambiare qualsiasi cosa

Osserva i due percorsi separatamente. Con il tunnel attivo, una sonda riporta l'uscita; con il tunnel spento, o con la sonda legata all'interfaccia fisica, riporta l'indirizzo di casa: curl --interface eth0 https://ifconfig.me. Se queste due risposte differiscono, hai riprodotto il difetto senza toccare l'aggiornatore.

Poi esegui il client in una modalità che controlla la configurazione senza eseguire un aggiornamento, per esempio ddclient -verbose -noexec, e leggi quale metodo di scoperta ha scelto. L'output dettagliato nomina il metodo e il valore ottenuto, e questo è il fatto che ti serve prima di modificare qualsiasi cosa.

Indirizza la scoperta sul percorso scelto

Se il nome deve pubblicare l'indirizzo WAN domestico, la scoperta deve osservare proprio quell'indirizzo. Funzionano tre opzioni, in ordine approssimativo di preferenza: lascia che il router pubblichi tramite il proprio aggiornatore supportato; usa la scoperta dello stato del router di ddclient contro una pagina che il router serve davvero; oppure mantieni una sonda web ma legala all'interfaccia fisica così esce fuori dal tunnel.

Per il percorso dello stato del router, le versioni recenti di ddclient usano la famiglia di opzioni usev4 e fwv4, con un modello di salto facoltativo per il testo attorno alla pagina. Controlla il README della versione installata, perché le versioni più vecchie scrivono la stessa idea con use e fw, e un nome di opzione copiato dalla versione sbagliata fallisce all'avvio.

Se mantieni la scoperta web, ricorda che instradare la sonda e instradare la chiamata all'API di aggiornamento sono decisioni separate. La chiamata di aggiornamento consegna il record; la sonda decide il valore che viene consegnato.

Tieni in ordine segreti e versioni

Le credenziali del router e i token del provider vanno in un file di configurazione protetto, non su una riga di comando che finisce nella cronologia della shell. Le tracce dettagliate possono contenere entrambi, quindi oscurale prima di incollarle in un ticket. Un metodo di scoperta che richiede di estrarre una pagina autenticata del router richiede anche di mantenere quella credenziale funzionante attraverso gli aggiornamenti del firmware. Conservala con la stessa cura del token del provider.

Il ddclient README documenta gli approcci di scoperta e i loro nomi di opzione. Non mescolare risultati IPv4 e IPv6 in un unico record, e non dare per scontato che un'opzione presente in una versione esista in un'altra.

Verifica il valore, poi la raggiungibilità

Confronta l'indirizzo proposto con l'endpoint previsto prima di consentire un aggiornamento dal vivo, poi controlla il DNS autoritativo dopo un aggiornamento autorizzato e tieni conto delle cache dei resolver. Un TTL basso accorcia l'attesa; non rende corretto un valore sbagliato.

Solo quando il record è corretto dovresti provare il servizio in ingresso da una rete indipendente, con firewall e inoltro richiesti già approvati. Un record A corretto non dimostra un servizio raggiungibile, e un lease VPN statico può semplificare la denominazione privata senza riparare un nome host pubblico che punta al WAN sbagliato.