Migrar de uma VPN baseada em PPP sem copiar as suas premissas

Uma migração de VPN termina quando os utilizadores, os destinos, a resolução de nomes e o comportamento em caso de falha continuam corretos, não quando o novo cliente mostra um ícone verde. As implementações antigas baseadas em PPP transportam premissas que nunca foram escritas: um segredo partilhado que também era a única verificação de identidade, um pool de endereços fixo que a firewall tem na lista de permitidos, um sufixo DNS que o servidor envia. Substituir o protocolo sem inventariar essas premissas produz um túnel que completa o handshake e uma fronteira que não existe. A ordem abaixo é a que eu uso, e o último passo é aquele que as equipas saltam.

Passo 1: inventarie o que a ligação antiga fornece

O inventário escreve-se, não se memoriza. Registe os clientes suportados, os papéis de autenticação, os pools de endereços, as redes protegidas, os requisitos de DNS e as permissões de serviço de que cada grupo de utilizadores precisa.

Para L2TP/IPsec, separe explicitamente as duas camadas. A identidade do par IPsec autentica as máquinas; o PPP autentica o utilizador, normalmente com CHAP ou MSCHAPv2.

É nessa separação que as implementações antigas escondem as suas premissas. Uma chave pré-partilhada partilhada por todos os clientes autentica um grupo e não um dispositivo, e muitas vezes é a única coisa que alguma vez foi rodada. Se a conta PPP é o controlo real por utilizador, diga-o, porque a substituição tem de reproduzir esse controlo com algo que não seja uma cadeia partilhada. Registe também endereços de origem fixos e exceções de rede local, porque essas são as dependências que ninguém documenta até falharem.

Passo 2: conceba a substituição deliberadamente

Escolher a substituição é um mapeamento requisito a requisito: um protocolo e um cliente mantido que a organização suporte, com cada requisito de identidade e acesso a aterrar num mecanismo real. Um segredo partilhado não equivale automaticamente a uma chave ou certificado por dispositivo, e uma conta PPP por utilizador não equivale a um certificado de dispositivo.

Coordene os intervalos de endereços antes de tudo o resto, porque um pool substituto que se sobreponha a uma LAN doméstica ou de escritório cria uma falha que nada tem a ver com a força da cifra. Verifique o pool contra a mesma lista que construiu para o serviço antigo, mais o que o novo cliente assume por defeito. Confirme o encaminhamento de retorno para as redes protegidas e confirme que o novo cliente pode enviar ou documentar o sufixo DNS que o antigo enviava. Esses dois pontos geram mais pedidos de migração do que a própria mudança de protocolo.

Passo 3: implemente por etapas e verifique tanto a permissão como a negação

Implemente com um utilizador representativo e uma aplicação representativa. Inclua a resolução DNS privada no teste, porque um túnel que chega a um endereço mas não consegue resolver um nome interno só está migrado a metade. Inclua também o estado de indisponibilidade esperado: o que deve acontecer quando o túnel cai e se o cliente o impõe.

Depois teste um destino que deve continuar negado. Uma regra ampla de permissão temporária pode fazer o novo túnel parecer saudável enquanto retira silenciosamente a fronteira de autorização que o serviço antigo aplicava, e ninguém nota até uma auditoria. Compare os resultados de permissão e negação lado a lado, a partir do mesmo cliente, na mesma sessão. Mantenha o serviço antigo em funcionamento até as duas colunas corresponderem ao desenho.

Antes de mover o acesso de administrador, confirme que tem um caminho de recuperação autorizado que não dependa do túnel que está a alterar.

Passo 4: retire a identidade antiga

Retirar corretamente a identidade antiga significa revogar os utilizadores e as credenciais de dispositivo obsoletos através do serviço que os possui, e depois remover perfis e ouvintes antigos quando já não resta qualquer dependência. Apagar um ficheiro local não revoga uma cópia noutro sítio, e um ouvinte antigo que ainda aceita o segredo partilhado antigo é uma porta sem vigilância.

Vale a pena abrandar nesse ponto. Um perfil de cliente desativado num portátil não é uma credencial revogada; a credencial vive no servidor e continua válida até o servidor deixar de a aceitar. Procure outras cópias da configuração antiga — dispositivos de teste, um telemóvel esquecido, um instalador que alguém guardou — e trate o desligamento do ouvinte como o momento em que o serviço antigo termina realmente. Até lá, a migração tem duas portas da frente.

O registo de aceitação é o inventário do primeiro passo com uma coluna acrescentada: o que o novo desenho faz para cada linha e como o verificou. Isso transforma uma atualização de protocolo num requisito de serviço com provas.

Mantenha o resultado ligado ao que o serviço precisa e não ao nome do protocolo, porque um protocolo moderno com as premissas antigas copiadas para dentro é o mesmo risco com melhor enquadramento. RFC 3193 descreve como o L2TP é transportado sobre IPsec, o que é um lembrete útil de que as duas camadas sempre foram decisões separadas. Se o inventário tiver uma linha que não consegue explicar, pare e descubra o que depende dela. A migração termina quando a lista é aborrecida.