Ti serve un DNS dinamico per un server VPN domestico?

La maggior parte dei guasti VPN domestici che mi vengono raccontati non sono guasti DNS, eppure le persone comprano prima un abbonamento DNS dinamico. Prima di configurare qualsiasi cosa, decidi se il nome host è la parte che è davvero rotta. Un updater riscrive un record quando l’indirizzo che ti ha dato il provider si sposta; non può aprire una porta, attraversare il NAT dell’operatore né far accorgere una sessione WireGuard attiva che il suo endpoint è cambiato. Tre condizioni decidono se il DNS dinamico è tutta la soluzione o solo una sua riga.

Prima condizione: il tuo indirizzo si sposta davvero

Gli indirizzi residenziali si spostano per motivi banali: il modem si risincronizza dopo un blackout, il provider riequilibra un pool, un nuovo lease arriva dopo un guasto lungo. Su alcune linee si spostano anche raramente, e ho visto lo stesso indirizzo sopravvivere un anno; i piani business spesso includono un indirizzo statico. Se nulla è cambiato in dodici mesi, un solo record A che modifichi a mano è un daemon in meno da tenere vivo.

Misuralo invece di indovinare. Leggi l’indirizzo WAN nella pagina di stato del router e confrontalo con ciò che vede il mondo esterno. Esegui questo da una macchina sulla LAN:

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

Se i due valori differiscono, qualcosa traduce davanti al router e nessun aggiornamento del nome host lo sistemerà. Un indirizzo dentro 100.64.0.0/10 è l’intervallo condiviso per il NAT di livello operatore, ed è il motivo abituale per cui un nome aggiornato correttamente scade comunque dall’esterno.

Seconda condizione: i client risolvono di nuovo il nome

Il TTL corto è la parte che la gente salta. I resolver ricorsivi rispettano il TTL del record, ma gli stack dei client fanno cache separatamente, e un tunnel già attivo non risolve nulla di nuovo. Imposta il record a 60-300 secondi mentre fai debug; questo accorcia la finestra in cui viene servita una risposta vecchia e non migra una sessione connessa.

OpenVPN risolve di nuovo la riga remote vpn.example.net 1194 a ogni riconnessione, e resolv-retry infinite lo tiene a riprovare invece di uscire quando la risoluzione fallisce. Sul server, float permette a una sessione stabilita di seguire un peer il cui indirizzo sorgente è cambiato. WireGuard è più diretto: wg-quick up risolve l’Endpoint quando viene applicata la configurazione, e il client lo risolve di nuovo quando ricostruisce il tunnel, quindi un handshake che riesce ancora verso il vecchio indirizzo continua a riuscire finché non si ferma.

Questa differenza dà forma al piano. Se i client si connettono su richiesta, un cambio di indirizzo costa una riconnessione. Se tengono una sessione aperta per giorni, aspettati che il tunnel muoia al prossimo handshake, e fai riprovare il client invece di dare per scontato che resti su.

Terza condizione: il percorso in ingresso è ancora aperto

Il DNS dinamico cambia solo dove punta il nome e nient’altro. L’inoltro di porta sul router, la regola del firewall sull’host VPN e il permesso del provider ai pacchetti in ingresso devono tutti esistere prima che il record conti. Guarda cosa punta l’inoltro: se è fissato a un indirizzo WAN invece che all’interfaccia, un cambio di indirizzo rompe l’inoltro in silenzio e il record si prende la colpa.

Prova dall’esterno. Un telefono su dati cellulare con il Wi-Fi spento è il test onesto più economico; un portatile sulla stessa LAN non lo è. Quando il nome risolve al tuo indirizzo pubblico e il router non ha loopback NAT, un test interno fallisce mentre il record è perfettamente corretto, e questo manda la maggior parte delle persone a modificare un record che non era mai sbagliato.

Cosa eseguire quando tutte e tre valgono

ddclient è l’updater meno sorprendente per un host piccolo. Una configurazione minima pubblica l’indirizzo che vede il provider, il che aggira l’errore del doppio NAT:

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

Eseguilo da un timer systemd ogni pochi minuti invece che in un ciclo shell, e registra la risposta del provider invece di dare per scontato il successo. Tratta la credenziale come una chiave, perché decide dove viene mandato ogni client: usa un token di aggiornamento limitato invece di una password dell’account, tieni il file in modalità 0600 e invia gli aggiornamenti su HTTPS.

Verifica prima di impegnarti

Una query ti dice cosa vede il resto del mondo e stampa il TTL che devi aspettare dopo un cambio:

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

Confronta quell’indirizzo con l’indirizzo WAN del router. Se coincidono, il nome fa il suo lavoro e ciò che ancora fallisce è raggiungibilità in ingresso, una chiave o un client che non ha risolto di nuovo. Se differiscono, l’updater pubblica l’interfaccia sbagliata, spesso perché girava sull’host VPN dietro il router invece che sul router stesso.

Tieni un ripristino che richiede un minuto: annota l’ultimo indirizzo funzionante e il TTL precedente, così puoi pubblicare entrambi a mano mentre il provider ha un pomeriggio storto.

Quando la risposta è no

Se la prima o la terza condizione fallisce, cambia la decisione, non la configurazione. Dietro il NAT dell’operatore le opzioni pratiche sono chiedere un indirizzo pubblico al provider, spostare il punto d’ingresso su un piccolo VPS con indirizzo stabile, o usare un overlay che mantiene il proprio rendez-vous. Se l’indirizzo è statico, salta l’updater: un record A, un record AAAA se usi IPv6, lo stesso inoltro di porta.

Se l’indirizzo cambia mentre i client restano connessi, la correzione onesta vive nel client: logica di riconnessione e intervallo di nuovo tentativo, non un updater più veloce. Aggiungere un secondo provider nasconde solo l’intervallo.

Prima di andare avanti, conferma quattro cose in ordine:

• L’indirizzo pubblicato dall’updater corrisponde all’indirizzo WAN del router.
• Il TTL del record è abbastanza corto perché un cambio compaia in pochi minuti.
• L’inoltro di porta è legato all’interfaccia, non a un indirizzo fisso.
• Un client reale si è riconnesso e ha fatto passare traffico dall’ultimo cambio.

Se tutte e quattro valgono, lascia stare la configurazione; il prossimo guasto è una chiave o una regola del firewall, non un problema di nomi. Se una fallisce, correggi quella riga prima di aggiungere un’altra parte mobile. RFC 2136 descrive il meccanismo di aggiornamento stesso, se vuoi vedere cosa mette il daemon sul filo.