La VPN si è spostata: perché il client OpenVPN compone ancora il vecchio IP

Il provider ha cambiato il tuo indirizzo pubblico, hai aggiornato il record DNS dinamico e il client ancora non riesce a connettersi. Dall’esterno sembra che il record non si sia propagato. Il più delle volte il record è corretto e il client compone l’indirizzo che aveva risolto prima del trasloco, perché un tunnel in esecuzione e un profilo salvato hanno ciascuno la propria idea di dove vive il server. Tre livelli devono concordare, e si aggiornano con calendari diversi.

Guarda cosa compone il profilo, non cosa dice il DNS

Apri la connessione che usi davvero e leggi la riga remote. Un indirizzo numerico lì non segue mai un aggiornamento del nome host, per quanto il record diventi corretto.

Poi controlla se il profilo che hai modificato è quello che il client ha caricato. I profili importati sono comuni: un amministratore può aver preso una copia mesi fa e tenuto la propria versione, così il file nella cartella dei download e la voce nell’app possono divergere. Confronta l’endpoint nei dettagli di connessione del client stesso prima ancora di eseguire il debug del DNS.

Due file, un endpoint: è il riscontro abituale qui.

grep -nE '^remote|^resolv-retry|^persist-remote-ip|^float' client.ovpn
printf 'resolver says: '; dig +short vpn.example.net

Leggi il prossimo tentativo di connessione del client

Riavvia la connessione con registrazione dettagliata e leggi la riga in cui è indicato l’indirizzo che contatterà. È quel valore che conta, non quello risolto dal browser.

La cache del resolver può ancora conservare la risposta precedente, e alcune reti la tengono più a lungo di quanto chieda il TTL del record. Interroga il resolver che il client usa davvero, non uno pubblico provato da altrove.

Se il registro mostra il nuovo indirizzo e la connessione fallisce ancora, il problema si è spostato: il pacchetto va da qualche parte e nessuno risponde. È una questione di listener, firewall o inoltro di porta, e sta dal lato server, non nel percorso di risoluzione del client. Tieni separati questi due guasti, perché trattare un listener irraggiungibile come problema DNS ti fa girare due volte nello stesso ciclo.

Sapere quale riavvio stai facendo

Non tutti i riavvii conservano lo stesso stato, per questo un cambio di indirizzo può comportarsi diversamente a seconda di come viene riciclato il processo. Un riavvio morbido innescato da un segnale conserva più contesto della sessione precedente, mentre un arresto e avvio completi ripartono dalla configurazione. Se stai verificando se il client risolve di nuovo, vuoi il percorso che parte dalla configurazione.

Anche le impostazioni di persistenza contano, perché sono pensate per conservare ciò che è stato autenticato, non per inseguire nuovi indirizzi.

Il test più pulito è un avvio da zero dal profilo previsto, seguito da un’occhiata alla riga di registro che nomina l’endpoint. Qualunque cosa impari da una sessione conservata in parte è un’affermazione su quella sessione.

Le quattro opzioni e i loro compiti separati

remote con un nome host è l’impostazione che rende possibile la nuova risoluzione; un indirizzo letterale su quella riga la esclude. resolv-retry controlla cosa accade quando una ricerca fallisce, e la 2.6 lo imposta già a infinito per impostazione predefinita. Aggiungerlo quindi non cambia nulla, e non pianifica mai un controllo periodico di una risposta diversa. Chi dice che sonda nuovi indirizzi ha confuso il ripristino con la freschezza.

persist-remote-ip riguarda la continuità, non la freschezza: riutilizza l’endpoint che si è autenticato per ultimo, attraverso i riavvii morbidi che supporta. Mentre provi un trasloco, è l’opposto di ciò che vuoi. Disattivalo per il test se la tua build lo abilita, poi ripristinalo quando il nuovo endpoint è dimostrato. Lasciato attivo, una riconnessione riuscita può non dirti nulla sul DNS.

float accetta un peer autenticato il cui indirizzo è cambiato a metà sessione, e solo in configurazioni che lo supportano. Non aggiorna il DNS e non seguirà da solo un cambio di provider. Trattalo come una funzione di resilienza per peer che si spostano, non come un meccanismo di indirizzi dinamici per i server.

Conferma il nuovo endpoint prima di dare la colpa al client

Dall’esterno della tua rete, verifica che il nuovo indirizzo abbia un listener sulla porta configurata e che l’inoltro del provider punti a esso. Un record A corretto per una macchina senza porta aperta produce esattamente il sintomo che le persone attribuiscono alla cache.

Poi riconnettiti e verifica due cose: il client si è autenticato contro il certificato del server atteso e la sessione raggiunge la risorsa che intendevi. Un cambio di indirizzo non abbassa i requisiti di identità, e una connessione che riesce verso l’endpoint sbagliato è peggiore di una che fallisce. Il manuale di OpenVPN 2.6 elenca tutte e quattro le opzioni con il loro ambito, ed è la lista di controllo da tenere accanto al profilo.

Mantieni un accesso fuori banda al server prima di riavviare il tunnel che porta il tuo accesso amministrativo. Quella sola precauzione previene la maggior parte degli incidenti che questo scenario produce.