Enrutador novo, mesmo servidor VPN: mova a súa entrada pública

Conecta o enrutador novo, volve internet e o cliente VPN do teléfono segue apuntando a un enderezo que xa non responde. No servidor VPN non cambiou nada, porque o servidor nunca se moveu. O enrutador era o punto de entrada público, e substituílo substituíu o enderezo, a regra de reenvío e quizais o actualizador de DNS dinámico ao mesmo tempo.

Trate o cambio como dúas transferencias, non unha, e manteña unha vía local á interface de administración mentres traballa.

Anote a transferencia antes de desconectar

Rexistre o prefixo de LAN, o enderezo do servidor e como se asigna, o escoitante e o transporte que o VPN usa en realidade, a regra de entrada que o publica e o nome que gardaron os clientes. Despois anote que máquina actualiza hoxe o rexistro de DNS dinámico: pode ser o enrutador, o propio servidor ou un axente aparte noutro host. Fágao mentres as páxinas de administración antigas aínda cargan. Unha captura de pantalla da regra de entrada vale máis que un número de porto recordado.

Engada os prefixos privados aos que os clientes deben chegar e como os dispositivos da LAN lles envían as respostas de volta. Os dous esquécense con facilidade porque o asistente de substitución fala de acceso a internet, non de camiños de volta. Exporte tamén a configuración antiga se o fabricante admite restaurala, aceptando que unha copia dun modelo raramente se importa limpa noutro.

Garde ese rexistro nun lugar protexido. Unha copia de seguridade do enrutador pode conter credenciais para a ligazón WAN. Trate o ficheiro exportado como un contrasinal e non como unha nota de axustes.

Mova primeiro o enderezo e despois o reenvío

Se o enrutador novo conserva o mesmo prefixo de LAN, dea ao servidor a reserva que tiña ou unha asignación estática equivalente. Se o prefixo cambia, actualice primeiro o enderezo do servidor e calquera vinculación de escoitante que o nomee, porque un reenvío cara ao enderezo antigo enviará o tráfico en silencio a ningures.

Despois recree exactamente unha regra de entrada para o transporte que usa o VPN. As guías de fabricante que describen o reenvío a un servidor local mostran o mecanismo, non unha receita universal, así que adapte a regra ao seu protocolo e porto reais e non a unha lista dun blog. Un reenvío no enrutador novo non pode eliminar o NAT de nivel de operador que está por riba, e ningunha regra local fará que un enderezo privado sexa accesible desde internet se o provedor xa comparte un con vostede.

Confirme que a devasa do propio servidor segue permitindo ese tráfico. Comprobe se entre o enrutador e internet hai unha segunda pasarela, porque moitos provedores entregan módem e enrutador combinados. Lea o enderezo WAN do dispositivo novo e compáreo co enderezo que resolven os clientes. Se difiren, o seu reenvío está a aterrar en algo que non é a beira.

Decida quen actualiza o nome público

As actualizacións do punto final necesitan un propietario e só un. Se o enrutador antigo publicaba o nome, configure un actualizador compatible no substituto e confirme que o rexistro cambiou de verdade. Se o servidor xa o publicaba, deixe esa disposición tranquila en lugar de engadir un actualizador rival que oscila entre dous enderezos.

Cando o despregamento publica as dúas familias de enderezos, lea tanto o rexistro A como o AAAA. Cada un ten que apuntar a un servizo que escoita de verdade e que está permitido polo seu propio camiño de devasa, e unha asignación IPv4 que funciona non di nada do lado IPv6. Manteña tamén as comprobacións de identidade no perfil do cliente: un enderezo público cambiado non é motivo para aceptar un certificado ou unha clave de par que non coincida.

Demostre o cambio desde fóra

Probe cunha conexión externa autorizada e unha sesión nova, non desde dentro da LAN. Unha proba interna contra o enderezo público depende do comportamento de retorno cara ao mesmo enderezo e percorre un camiño distinto do que fará un cliente real.

Siga a secuencia que segue un cliente: resolva o nome, negocie o túnel, autentíquese e despois realice unha operación contra un recurso privado. Ese último paso é o que a xente salta, e é o único que demostra o camiño de volta. Se o inicio de sesión funciona pero a operación privada falla, compare o prefixo de LAN novo, as rutas que escolleu o cliente e o camiño de resposta do recurso coas súas notas de transferencia.

Só cando pasan os catro pasos o enrutador antigo se pode retirar con seguridade. Desconécteo e repita a proba externa unha vez máis. Un rexistro obsoleto que aínda resolve ao enderezo antigo falla xa no primeiro paso, e iso é máis fácil de diagnosticar mentres o dispositivo antigo segue na estantería.

Garde a nova asignación coas súas notas de recuperación

Arquive a asignación final do servidor, a regra de entrada e o nome do propietario da actualización xunto ao procedemento para chegar ao enrutador localmente. A seguinte substitución debería comezar nesa páxina e non nun traceroute.

Se o túnel segue fallando desde fóra despois de todo o anterior, comprobe se o enderezo público que informa o enrutador coincide co que resolven os clientes. Esa única comparación separa un problema de DNS dun problema de reenvío, e leva menos tempo que ler outra guía de reenvío de portos.