Moure un servidor VPN a una nova IP pública: què cal comprovar primer

Reassignar una adreça dura un minut. La setmana següent és on es trenca el trasllat, i poques vegades on ho suggereix la consola del proveïdor. Una IP pública nova es referencia en quatre llocs: el sòcol on escolta el dimoni, l’àncora de confiança que verifiquen els clients, cada regla que nomena l’adreça antiga i el registre DNS que els lliga. Dos trasllats semblen idèntics des d’un panell de control però es comporten de manera ben diferent: reassignar l’adreça a la màquina que executeu, o aixecar un segon endpoint i moure-hi els clients. Les comprovacions de sota posen primer les fallades barates, i cada secció indica a quin trasllat s’aplica.

La substitució in situ i el tall paral·lel són feines diferents

La substitució in situ conserva l’amfitrió, les claus, la taula d’encaminament i la llista d’usuaris; només canvia l’adreça. Això és el que fa una reassignació d’IP flotant, i en diversos proveïdors el convidat no se n’assabenta, perquè la traducció passa davant de la instància. Una reconstrucció o una reassignació del proveïdor és més dura: el convidat veu el canvi, i tot el que havia fet memòria cau del valor antic ho aprèn en el mateix moment.

Un endpoint paral·lel és un segon amfitrió que fa la mateixa feina. Construïu-lo, proveu-lo amb un perfil i deixeu que el vell respongui fins que el nou es demostri per un camí real. El preu és l’estat. Sense entrades de peer compartides, revocacions i registres, teniu dues xarxes que casualment comparteixen un nom.

Trobeu cada lloc on hi ha escrita l’adreça antiga

Comenceu amb un escombrat de text, perquè els fitxers de configuració són la meitat fàcil. Cerqueu la configuració del dimoni, els fragments de tallafoc, els objectius de monitoratge i qualsevol paquet de client generat al disc. Incloeu l’adreça IPv6 si en publiqueu una; un trasllat que només segueix el registre A deixa els clients de doble pila al camí vell.

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

Després escombreu el nucli, perquè un sistema en marxa guarda l’adreça en llocs que cap fitxer esmenta. Una regla NAT d’origen estàtica, una entrada d’ipset, una adreça d’escolta i una entrada de conntrack sobreviuen a l’edició de configuració que les va eliminar, i algunes sobreviuen a un reinici perquè han tornat d’un conjunt de regles desat. Una capa més amunt, els grups de seguretat del proveïdor, els objectius del balancejador i les comprovacions de monitoratge no són gens al vostre sistema de fitxers.

Escriviu l’inventari abans de canviar res; també fa de guió de reversió.

Els clients amb nom d’amfitrió es recuperen; els clients amb IP literal callen

Si els clients arriben al servidor pel nom d’amfitrió, el tall és sobretot un problema de DNS, i el TTL que vau fixar ahir decideix com n’és de dolent. Els resoledors fan memòria cau, els resoledors stub en fan una altra, i molts clients només busquen el nom en una connexió nova, així que un túnel establert conserva la seva adreça inicial.

Si l’endpoint és una adreça literal, res no torna a resoldre’s i res no enregistra cap queixa. WireGuard desa una adreça de sòcol resolta: Endpoint = vpn.example.net:51820 es converteix en una IP en el moment que wg-quick up s’executa i es queda aquesta IP fins que la canvieu. OpenVPN és més indulgent: resol el nom d’amfitrió remote en el moment de connectar i, amb resolv-retry infinite, torna a provar el DNS en reconnectar. Amb una IP literal, tots dos continuen marcant una màquina que ja no existeix.

El que enganya la gent és la imatge del mirall. Un client ja adreçat a l’adreça nova, mentre l’escoltador vell encara respon, passa cada prova que feu des del vostre escriptori. Jo m’hi he deixat enganyar: el nou endpoint va pujar en un telèfon al primer intent, i un client amb un perfil obsolet només va aparèixer quan l’escoltador vell es va apagar molt més tard.

La confiança no es mou amb l’adreça

WireGuard separa la identitat de l’abastabilitat, cosa que fa gairebé gratuït moure una adreça. Els peers s’identifiquen per clau pública, i l’endpoint només és on van els paquets ara; un amfitrió actualitza l’endpoint d’un peer a partir de l’adreça d’origen del paquet autenticat més recent. Un peer inactiu encara necessita un motiu per parlar amb el lloc nou, i aprèn l’adreça només quan la seva sessió caduca i els reintents de handshake fallen en algun lloc visible. L’inici ràpid de WireGuard cobreix el camp endpoint.

Els servidors basats en TLS són el cas oposat. El certificat està lligat a un nom, i un client que marca una adreça compara el que ha marcat amb els noms alternatius del subjecte. Connecteu per IP a un certificat que només porta un SAN de DNS i la verificació falla: el nom que ha usat el client no és al certificat. Reemetre amb un SAN d’IP arregla aquella connexió i fa pitjor el trasllat següent. Mantenir un nom d’amfitrió al perfil i deixar verify-x509-name al seu lloc manté la comprovació estricta mentre l’adreça de sota canvia.

Després comproveu a què està lligat el dimoni; un sòcol fixat a l’adreça antiga falla en silenci. Un servidor OpenVPN engegat amb local 203.0.113.10 es nega a aixecar-se un cop l’adreça ha desaparegut, mentre que un escoltador a 0.0.0.0 segueix el canvi de franc. El NAT es parteix igual: MASQUERADE segueix qualsevol adreça que ara tingui la màquina, i un SNAT --to-source 203.0.113.10 estàtic continua reescrivint cap a una adreça que ja no posseïu, així que el trànsit de retorn desapareix. Si l’adreça nova ve amb una passarel·la upstream diferent, comproveu rp_filter: el filtratge de camí invers descarta el trànsit de retorn que arriba per una interfície que el nucli no esperava.

Ordre del tall i les proves que ha funcionat

Baixeu el TTL un dia abans, aixequen el nou escoltador i demostreu-lo amb un perfil que només tingueu vosaltres. Una prova des de dins de la mateixa xarxa no demostra gairebé res, així que feu servir un telèfon amb dades mòbils i proveu una cosa que el túnel ha de portar, no un ping a l’endpoint.

Vigileu les dues adreces durant la finestra. wg show all latest-handshakes a l’amfitrió nou, o el fitxer d’estat d’OpenVPN, us diu quants peers s’han mogut de debò. Quan el nou endpoint tingui els peers que espereu i el vell només tingui endarrerits, retirar l’escoltador vell, traieu la regla NAT obsoleta i treieu l’adreça del tallafoc del proveïdor. Retirar l’escoltador vell és el pas que es descuida, i tanca la bretxa on un perfil obsolet encara arriba a la xarxa antiga.

Fixeu el desencadenant de reversió per escrit abans de començar: si el nou endpoint no ha fet cap handshake amb un sol client real després de la finestra acordada, restaureu l’adreça antiga i deixeu de distribuir perfils. Torneu a executar l’escombrat després i confirmeu que cap escoltador continua lligat a una adreça retirada. Dues coses passen al trasllat següent: un nom d’amfitrió al perfil del client perquè el canvi següent sigui una edició de DNS, i l’inventari desat al costat de les notes de recuperació del servidor.