Spostare un server VPN su un nuovo IP pubblico: cosa controllare per primo

Riassegnare un indirizzo richiede un minuto. La settimana successiva è il punto in cui lo spostamento si rompe, e raramente dove lo suggerisce la console del provider. Un nuovo IP pubblico è referenziato in quattro punti: il socket su cui ascolta il demone, l'ancora di fiducia che i client verificano, ogni regola che nomina il vecchio indirizzo e il record DNS che li lega. Due spostamenti sembrano identici da un pannello di controllo ma si comportano in modo del tutto diverso: riassegnare l'indirizzo sulla macchina che gestite, oppure alzare un secondo endpoint e spostare lì i client. I controlli qui sotto mettono prima i guasti economici, e ogni sezione indica a quale spostamento si applica.

La sostituzione in sede e il passaggio parallelo sono lavori diversi

La sostituzione in sede mantiene l'host, le chiavi, la tabella di routing e l'elenco utenti; cambia solo l'indirizzo. È ciò che fa una riassegnazione di IP mobile, e presso diversi provider l'ospite non se ne accorge, perché la traduzione avviene davanti all'istanza. Una ricostruzione o una riassegnazione del provider è più dura: l'ospite vede il cambiamento, e tutto ciò che aveva messo in cache il vecchio valore lo apprende nello stesso momento.

Un endpoint parallelo è un secondo host che fa lo stesso lavoro. Costruitelo, provatelo con un profilo e lasciate che il vecchio risponda finché il nuovo non si dimostra su un percorso reale. Il prezzo è lo stato. Senza voci peer condivise, revoche e registrazione, avete due reti che per caso condividono un nome.

Trovate ogni punto in cui è scritto il vecchio indirizzo

Iniziate con una scansione testuale, perché i file di configurazione sono la metà facile. Cercate nella configurazione del demone, nei frammenti del firewall, nei target di monitoraggio e in qualsiasi bundle client generato sul disco. Includete l'indirizzo IPv6 se ne pubblicate uno; uno spostamento che segue solo il record A lascia i client dual-stack sul vecchio percorso.

OLD=203.0.113.10
grep -RIn -- "$OLD" /etc /root
ss -lunpt | grep -F "$OLD"
nft list ruleset | grep -F "$OLD"
iptables-save | grep -F "$OLD"
wg show all endpoints

Poi passate il kernel, perché un sistema in esecuzione tiene l'indirizzo in punti che nessun file menziona. Una regola NAT sorgente statica, una voce ipset, un indirizzo di bind e una voce conntrack sopravvivono alla modifica di configurazione che le ha rimosse, e alcune sopravvivono a un riavvio perché sono tornate da un set di regole salvato. Un livello più su, i gruppi di sicurezza del provider, i target del bilanciatore e i controlli di monitoraggio non sono affatto sul vostro filesystem.

Scrivete l'inventario prima di cambiare qualsiasi cosa; serve anche come script di rollback.

I client per nome host si riprendono; i client con IP letterale tacciono

Se i client raggiungono il server tramite nome host, il passaggio è soprattutto un problema DNS, e il TTL impostato ieri decide quanto sarà grave. I resolver mettono in cache, i resolver stub rimettono, e molti client cercano il nome solo su una nuova connessione, quindi un tunnel già stabilito conserva il suo indirizzo iniziale.

Se l'endpoint è un indirizzo letterale, nulla viene risolto di nuovo e nulla registra un reclamo. WireGuard memorizza un indirizzo di socket risolto: Endpoint = vpn.example.net:51820 diventa un IP nel momento in cui gira wg-quick up e resta quell'IP finché non lo cambiate. OpenVPN è più indulgente: risolve il nome host remote al momento della connessione e, con resolv-retry infinite, riprova il DNS alla riconnessione. Con un IP letterale, entrambi continuano a chiamare una macchina che non esiste più.

Ciò che inganna le persone è l'immagine allo specchio. Un client già puntato al nuovo indirizzo, mentre il vecchio listener risponde ancora, supera ogni test che fate dalla vostra scrivania. Ci sono cascato anch'io: il nuovo endpoint è salito su un telefono al primo tentativo, e un client con un profilo obsoleto è emerso solo quando il vecchio listener è stato spento molto più tardi.

La fiducia non si sposta con l'indirizzo

WireGuard separa l'identità dalla raggiungibilità, il che rende quasi gratuito spostare un indirizzo. I peer sono identificati dalla chiave pubblica, e l'endpoint è solo dove vanno i pacchetti in questo momento; un host aggiorna l'endpoint di un peer dall'indirizzo sorgente dell'ultimo pacchetto autenticato. Un peer inattivo ha comunque bisogno di un motivo per parlare con il nuovo posto, e impara l'indirizzo solo quando la sua sessione invecchia e i tentativi di handshake falliscono in un punto visibile. La guida rapida di WireGuard copre il campo endpoint.

I server basati su TLS sono il caso opposto. Il certificato è legato a un nome, e un client che compone un indirizzo confronta ciò che ha composto con i nomi alternativi del soggetto. Collegatevi via IP a un certificato che porta solo un SAN DNS e la verifica fallisce: il nome usato dal client non è nel certificato. Riemettere con un SAN IP corregge quella singola connessione e peggiora lo spostamento successivo. Tenere un nome host nel profilo e lasciare verify-x509-name al suo posto mantiene il controllo severo mentre l'indirizzo sotto cambia.

Poi controllate a cosa è legato il demone; un socket fissato al vecchio indirizzo fallisce in silenzio. Un server OpenVPN avviato con local 203.0.113.10 rifiuta di salire una volta che quell'indirizzo è sparito, mentre un listener su 0.0.0.0 segue il cambiamento gratis. Il NAT si divide allo stesso modo: MASQUERADE segue qualunque indirizzo la macchina abbia ora, e un SNAT --to-source 203.0.113.10 statico continua a riscrivere verso un indirizzo che non possedete più, così il traffico di ritorno svanisce. Se il nuovo indirizzo arriva con un gateway upstream diverso, controllate rp_filter: il filtro di percorso inverso scarta il traffico di ritorno che arriva su un'interfaccia che il kernel non si aspettava.

Ordine del passaggio e le prove che ha funzionato

Abbassate il TTL un giorno prima, alzate il nuovo listener e dimostratelo con un profilo che avete solo voi. Un test dall'interno della stessa rete non dimostra quasi nulla, quindi usate un telefono in rete mobile e testate qualcosa che il tunnel deve trasportare invece di un ping verso l'endpoint.

Sorvegliate entrambi gli indirizzi per tutta la finestra. wg show all latest-handshakes sul nuovo host, o il file di stato di OpenVPN, vi dice quanti peer si sono davvero spostati. Quando il nuovo endpoint ha i peer che vi aspettate e il vecchio solo ritardatari, ritirate il vecchio listener, rimuovete la regola NAT obsoleta e togliete l'indirizzo dal firewall del provider. Rimuovere il vecchio listener è il passo che si salta, e chiude la falla in cui un profilo obsoleto raggiunge ancora la vecchia rete.

Fissate per iscritto il trigger di rollback prima di iniziare: se il nuovo endpoint non ha handshake da un solo client reale dopo la finestra concordata, ripristinate il vecchio indirizzo e smettete di distribuire profili. Rilanciate la scansione dopo e confermate che nessun listener è ancora legato a un indirizzo ritirato. Due cose passano allo spostamento successivo: un nome host nel profilo del client perché la prossima modifica sia una modifica DNS, e l'inventario conservato accanto alle note di ripristino del server.