Encaminador nou, mateix servidor VPN: moveu-ne l’entrada pública

Connecteu l’encaminador nou, la internet torna, i el client VPN del telèfon encara apunta a una adreça que ja no respon. Al servidor VPN no ha canviat res, perquè el servidor no s’ha mogut mai. L’encaminador era el punt d’entrada públic, i substituir-lo va substituir l’adreça, la regla de reenviament i, potser, l’actualitzador de DNS dinàmic alhora.

Tracteu el canvi com dos lliuraments, no un, i manteniu una via local a la interfície d’administració mentre treballeu.

Anoteu el lliurament abans de desconnectar

Anoteu el prefix de LAN, l’adreça del servidor i com s’assigna, l’oient i el transport que el VPN fa servir de debò, la regla d’entrada que el publica i el nom que els clients han desat. Després apunteu quina màquina actualitza avui el registre de DNS dinàmic: pot ser l’encaminador, el mateix servidor o un agent separat en un altre amfitrió. Feu-ho mentre les pàgines d’administració antigues encara es carreguen. Una captura de pantalla de la regla d’entrada val més que un número de port recordat.

Afegiu els prefixos privats que els clients han d’assolir i com els dispositius de la LAN els envien les respostes de tornada. Tots dos són fàcils d’oblidar perquè l’assistent de substitució parla d’accés a internet, no de camins de tornada. Exporteu també la configuració antiga si el fabricant en permet la restauració, tot acceptant que una còpia d’un model poques vegades s’importa neta en un altre.

Guardeu aquest registre en un lloc protegit. Una còpia de seguretat de l’encaminador pot contenir credencials per a l’enllaç WAN. Tracteu el fitxer exportat com una contrasenya i no com una nota de paràmetres.

Primer moveu l’adreça, després el reenviament

Si l’encaminador nou conserva el mateix prefix de LAN, doneu al servidor la reserva que tenia o una assignació estàtica equivalent. Si el prefix canvia, actualitzeu primer l’adreça del servidor i qualsevol vincle d’oient que la nomeni, perquè un reenviament apuntat a l’adreça antiga enviarà el trànsit en silenci enlloc.

Després recreate exactament una regla d’entrada per al transport que fa servir el VPN. Les guies dels fabricants que descriuen el reenviament a un servidor local mostren el mecanisme, no una recepta universal, així que adapteu la regla al vostre protocol i port reals i no a una llista d’un blog. Un reenviament a l’encaminador nou no pot treure el NAT de nivell d’operador que hi ha per sobre, i cap regla local farà que una adreça privada sigui abastable des d’internet si el proveïdor ja en comparteix una amb vosaltres.

Confirmeu que el tallafoc del mateix servidor encara permet aquest trànsit. Comproveu si entre l’encaminador i internet hi ha una segona passarel·la, perquè molts proveïdors lliuren un mòdem i encaminador combinats. Llegiu l’adreça WAN al dispositiu nou i compareu-la amb l’adreça que resolen els clients. Si difereixen, el vostre reenviament aterra en una cosa que no és la vora.

Decidiu qui actualitza el nom públic

Les actualitzacions del punt final necessiten un propietari i només un. Si l’encaminador antic publicava el nom, configureu un actualitzador compatible al substitut i confirmeu que el registre ha canviat de debò. Si el servidor ja el publicava, deixeu aquesta disposició tranquil·la en lloc d’afegir-hi un actualitzador rival que oscil·la entre dues adreces.

Quan el desplegament publica les dues famílies d’adreces, llegiu tant el registre A com l’AAAA. Cadascun ha d’apuntar a un servei que escolta de debò i que està permès pel seu propi camí de tallafoc, i una assignació IPv4 que funciona no diu res sobre el costat IPv6. Manteniu també les comprovacions d’identitat al perfil del client: una adreça pública canviada no és motiu per acceptar un certificat o una clau d’igual que no coincideixi.

Demostreu el canvi des de fora

Proveu amb una connexió externa autoritzada i una sessió nova, no des de dins de la LAN. Una prova interna contra l’adreça pública depèn del comportament de retorn cap a la mateixa adreça i recorre un camí diferent del que farà un client real.

Seguiu la seqüència que segueix un client: resoleu el nom, negocieu el túnel, autentiqueu-vos i després feu una operació contra un recurs privat. Aquest darrer pas és el que la gent s’estalvia, i és l’únic que demostra el camí de tornada. Si l’inici de sessió funciona però l’operació privada falla, compareu el prefix de LAN nou, les rutes que el client ha triat i el camí de resposta del recurs amb les vostres notes de lliurament.

Només quan passen les quatre passes l’encaminador antic es pot retirar amb seguretat. Desconnecteu-lo i repetiu la prova externa un cop més. Un registre obsolet que encara resol a l’adreça antiga falla a la primera passa, i això és més fàcil de diagnosticar mentre el dispositiu antic encara és a la prestatgeria.

Guardeu la nova assignació amb les vostres notes de recuperació

Arxiveu l’assignació final del servidor, la regla d’entrada i el nom del propietari de l’actualització al costat del procediment per arribar a l’encaminador localment. La propera substitució hauria de començar en aquesta pàgina i no en un traceroute.

Si el túnel encara falla des de fora després de tot l’anterior, comproveu si l’adreça pública que l’encaminador informa coincideix amb la que resolen els clients. Aquesta única comparació separa un problema de DNS d’un problema de reenviament, i triga menys que llegir una altra guia de reenviament de ports.