Cambiare provider VPN: pianificare il nome host, non solo l’IP

Il vostro record DNS è corretto, il sostituto è sano, eppure alcuni client passano ore a comporre l’indirizzo vecchio. Alcuni falliscono subito contro un nome che si risolve e non risponde mai. Entrambi i risultati nascono da una sola lacuna: un nome host cambia ciò che un client cerca, non quando lo cerca, né ciò di cui si fida quando arriva la risposta.

Il sintomo: un record corretto, tunnel obsoleti

Un profilo che memorizza un nome non è un client che continua a risolverlo. La maggior parte lo risolve una volta, all’applicazione della configurazione o quando il tunnel sale, poi riutilizza quell’indirizzo fino alla fine della sessione. Un TTL lungo sopra questo è il motivo per cui il passaggio va pianificato intorno alle riconnessioni e non intorno alla modifica del DNS.

Nessuno dei due comportamenti è un difetto, ed è proprio questo che rende il sintomo confuso. Il client lavora su una risposta ottenuta prima, e nulla lato server mostra quale fosse. Pianificate la riconnessione nella finestra di manutenzione e dite agli utenti cosa vedranno, oppure passate la finestra a rispondere ai ticket. Una coda di segnalazioni identiche è il risultato abituale.

Chi controlla il nome e cosa verifica il client

Il controllo della zona decide quanto velocemente può muoversi una migrazione. Tenete il record presso un registrar in cui potete accedere e annotate chi altro può cambiarlo.

La fiducia non segue il nome. Un client basato su TLS può controllare l’identità di un certificato o un nome fissato, mentre WireGuard autentica la chiave pubblica del peer e ignora del tutto il nome host. Questa differenza decide se basta una modifica DNS o se ogni profilo ha bisogno di una nuova impronta. Un cambio di record non dovrebbe mai autorizzare un endpoint che nessuno ha approvato.

Tenete l’accesso amministrativo e di ripristino lontano dal nome pubblico del client. Perdere un account di hosting non dovrebbe costarvi anche il record che reindirizza i client. Conservate il percorso di ripristino in un luogo che non dipenda dal provider che state lasciando.

Quando ogni client rilegge il nome

Il momento della risoluzione è una proprietà di ogni client, quindi controllate l’implementazione che distribuite davvero prima di promettere una finestra di passaggio. wg-quick risolve l’endpoint quando l’interfaccia sale e conserva quell’indirizzo finché il tunnel non viene riavviato. Un client OpenVPN cerca il nome quando si connette, e se guarda di nuovo alla riconnessione dipende dalle sue opzioni.

I client mobili sono la sorpresa abituale, perché possono mantenere un indirizzo risolto durante la sospensione o un cambio di rete. Pubblicate record A e AAAA solo se il sostituto risponde su entrambe le famiglie. Un indirizzo che risponde su una famiglia non prova nulla sull’altra, e un record AAAA morto aggiunge un timeout a ogni tentativo. Documentate il comportamento di risoluzione per ogni client che supportate, poi provate sui dispositivi che le persone usano davvero.

La riconnessione è un’azione dell’utente nella maggior parte dei client, e il server non può imporla. Inserite quel passaggio nella nota di manutenzione, con una riga su cosa vedrà l’utente quando accadrà.

Passate in base alle prove, poi ritirate il vecchio endpoint

Prima del passaggio, dimostrate ogni livello sul sostituto: il listener risponde, il firewall lascia passare la porta, le rotte tornano nel verso giusto, il nome si risolve sul nuovo indirizzo e un’identità nota viene accettata. Un listener che accetta una connessione non è la stessa cosa di uno che completa una stretta di mano, quindi provate la stretta di mano e non la porta. Tenete l’elenco di revoca attuale accanto alla configurazione, perché un backup ripristinato ricrea l’elenco dei peer com’era e riaprirebbe un accesso che avete già chiuso. Annotate con quale identità avete provato, perché «funziona» non è una prova che qualcuno possa ripetere.

getent hosts vpn.example.com
ss -lunp | grep 51820
wg show wg0 latest-handshakes

Durante la transizione, osservate i tentativi di connessione su entrambi gli endpoint per la stessa identità. Un client che si autentica ancora contro l’indirizzo vecchio è un profilo o una risposta in cache che non si è mai spostata. Ritirate il vecchio endpoint secondo un piano con data, perché due servizi che accettano una sola identità lasciano due porte aperte.

Il test del passaggio è una sessione applicativa attraverso il nuovo endpoint, non un ping. Quando quella sessione funziona e il vecchio endpoint non registra tentativi autorizzati per un ciclo completo di riconnessione, il trasferimento è finito.