Router novo, mesmo servidor VPN: mude a entrada pública dele
O servidor VPN fica na LAN, então trocar o router são duas passagens: o caminho até ele e a entrada pública que os clientes guardaram. Leve ambas e depois teste de fora.
Você liga o router novo, a internet volta, e o cliente VPN do telemóvel continua a apontar para um endereço que já não responde. No servidor VPN nada mudou, porque o servidor nunca se mudou. O router era o ponto de entrada pública, e substituí-lo substituiu o endereço, a regra de encaminhamento e talvez o atualizador de DNS dinâmico ao mesmo tempo.
Trate a troca como duas passagens, não uma, e mantenha um caminho local para a interface de administração enquanto trabalha.
Anote a passagem antes de desligar
Registe o prefixo de LAN, o endereço do servidor e como é atribuído, o ouvinte e o transporte que o VPN usa de facto, a regra de entrada que o publica e o nome que os clientes guardaram. Depois anote que máquina atualiza hoje o registo de DNS dinâmico: pode ser o router, o próprio servidor ou um agente separado noutro anfitrião. Faça isto enquanto as páginas de administração antigas ainda carregam. Uma captura de ecrã da regra de entrada vale mais do que um número de porta memorizado.
Acrescente os prefixos privados que os clientes devem alcançar e como os dispositivos da LAN lhes enviam as respostas de volta. Ambos são fáceis de esquecer, porque o assistente de substituição fala de acesso à internet, não de caminhos de retorno. Exporte também a configuração antiga se o fabricante suportar o restauro, aceitando que uma cópia de um modelo raramente se importa limpa noutro.
Guarde esse registo num local protegido. Uma cópia de segurança do router pode conter credenciais para o link WAN. Trate o ficheiro exportado como uma palavra-passe e não como uma nota de definições.
Mova primeiro o endereço, depois o encaminhamento
Se o router novo mantiver o mesmo prefixo de LAN, dê ao servidor a reserva que tinha, ou uma atribuição estática equivalente. Se o prefixo mudar, atualize primeiro o endereço do servidor e qualquer associação de ouvinte que o nomeie, porque um encaminhamento para o endereço antigo envia o tráfego silenciosamente para nenhum lado.
Depois recrie exatamente uma regra de entrada para o transporte que o VPN usa. Os guias de fabricante que descrevem o encaminhamento para um servidor local mostram o mecanismo, não uma receita universal, por isso adapte a regra ao seu protocolo e porta reais e não a uma lista de um blogue. Um encaminhamento no router novo não pode remover o NAT de nível de operador que está acima, e nenhuma regra local tornará um endereço privado acessível a partir da internet se o fornecedor já partilha um consigo.
Confirme que a firewall do próprio servidor ainda permite esse tráfego. Verifique se há uma segunda gateway entre o router e a internet, porque muitos fornecedores entregam modem e router combinados. Leia o endereço WAN no dispositivo novo e compare-o com o endereço que os clientes resolvem. Se diferirem, o seu encaminhamento está a aterrar em algo que não é a margem.
Decida quem atualiza o nome público
As atualizações do ponto final precisam de um proprietário e apenas um. Se o router antigo publicava o nome, configure um atualizador suportado no substituto e confirme que o registo mudou de facto. Se o servidor já o publicava, deixe essa disposição em paz em vez de acrescentar um atualizador concorrente que oscila entre dois endereços.
Quando a implementação publica as duas famílias de endereços, leia tanto o registo A como o AAAA. Cada um tem de apontar para um serviço que escuta realmente e que está autorizado pelo seu próprio caminho de firewall, e um mapeamento IPv4 a funcionar não diz nada sobre o lado IPv6. Mantenha também as verificações de identidade no perfil do cliente: um endereço público alterado não é motivo para aceitar um certificado ou uma chave de par que não corresponde.
Prove a troca de fora
Teste com uma ligação externa autorizada e uma sessão nova, não de dentro da LAN. Um teste interno contra o endereço público depende do comportamento de retorno ao próprio endereço e percorre um caminho diferente do que um cliente real fará.
Siga a sequência que um cliente segue: resolva o nome, negoceie o túnel, autentique-se e depois execute uma operação contra um recurso privado. É esse último passo que as pessoas saltam, e é o único que prova o caminho de retorno. Se o início de sessão funcionar mas a operação privada falhar, compare o prefixo de LAN novo, as rotas que o cliente escolheu e o caminho de resposta do recurso com as suas notas de passagem.
Só depois de passarem os quatro passos é seguro retirar o router antigo. Desligue-o e repita o teste externo mais uma vez. Um registo desatualizado que ainda resolve para o endereço antigo falha logo no primeiro passo, e isso é mais fácil de diagnosticar enquanto o dispositivo antigo ainda está na prateleira.
Guarde o novo mapeamento junto das suas notas de recuperação
Arquive a atribuição final do servidor, a regra de entrada e o nome do proprietário da atualização ao lado do procedimento para chegar ao router localmente. A próxima substituição deve começar nessa página e não num traceroute.
Se o túnel continuar a falhar de fora depois de tudo o que ficou acima, verifique se o endereço público que o router relata coincide com o que os clientes resolvem. Essa única comparação separa um problema de DNS de um problema de encaminhamento, e leva menos tempo do que ler outro guia de encaminhamento de portas.