O que uma migração de VPN deve preservar de um circuito privado

Circuitos privados são fáceis de descrever e difíceis de substituir, porque o contrato cobria mais do que um cabo. Ele carregava uma entrega, um plano de endereçamento, uma expectativa de latência e um acordo de suporte, e o túnel que o substitui herda os quatro, quer alguém os tenha escrito ou não. As migrações falham quando a equipe copia a configuração de roteamento e chama o resto de problema de operações. Comece pelos requisitos e depois comprove cada um no caminho novo antes de cancelar o antigo.

Transforme o circuito numa lista de propriedades

A primeira pergunta é o que o serviço antigo realmente entregou: um link roteado com uma sub-rede pequena, ou um segmento de camada 2 compartilhado entre sites. Essa distinção decide se um túnel IP consegue reproduzi-lo, porque um túnel transporta pacotes entre dois endereços e não transporta descoberta por broadcast nem EtherTypes arbitrários. Um circuito que se apresentava como porta de switch é uma migração diferente de um que apresentava uma /30.

Anote os prefixos dos sites, os endereços de gateway, as aplicações que embutem endereços na própria configuração e os prefixos que se sobrepõem noutro lugar do ambiente. Um plano de endereçamento que sobrevive à migração é um resultado de projeto, não uma suposição. Essas quatro listas também se tornam critérios de aceitação mais tarde, então guarde-as onde os testadores possam lê-las.

Encaminhe o caminho novo nos dois sentidos

Um túnel que sobe é apenas meio caminho. O lado remoto precisa de uma rota de volta para cada prefixo local, e o lado local deve preferir o túnel para esses prefixos sem roubar tráfego que ainda deve sair pela internet. O encaminhamento assimétrico é o sintoma habitual de acertar uma dessas metades. Inspecione a tabela do lado remoto com o mesmo cuidado que a sua, porque a rota de volta é a que ninguém configurou.

ip route get 10.20.0.10

O roteamento por políticas torna a divisão explícita: marque o tráfego que pertence ao par de sites e dê-lhe uma tabela cujo padrão é o túnel. O IPsec fornece a associação protegida e a política que decide o que entra nela, mas não as rotas ao seu redor, como a arquitetura IPsec descreve. Quando a marca corresponde de forma demasiado ampla, o tráfego web comum do site também entra no túnel e sai pela saída errada.

Troque com uma reversão que já testou

Dois caminhos vivos com proprietários diferentes convidam ao encaminhamento assimétrico, por isso suba o novo dentro de uma janela definida e mova os prefixos numa ordem declarada. Mantenha o circuito antigo configurado e conserve um caminho de gestão fora de banda que não dependa de nenhum dos túneis. Mova um prefixo de cada vez onde as aplicações o permitirem, e observe a tabela de sessões entre movimentos.

Decida antecipadamente que provas autorizam a troca e que condição desencadeia a reversão. Uma reversão que exige reparar a nova VPN através da ligação falhada não é uma reversão. Enuncie o gatilho como condição mensurável e não como uma sensação na sala.

Aceite com o tráfego que o circuito realmente carregava

Ping prova alcançabilidade e pouco mais. Teste a resolução de nomes, as sessões de longa duração, os fluxos negados e os tamanhos de pacote que o caminho antigo tratava sem fragmentação. A MTU é onde os túneis mais frequentemente diferem de um circuito, porque a encapsulação consome bytes que a aplicação assumia disponíveis. Meça a maior carga útil que passa sem fragmentação nos dois sentidos, não apenas para o servidor.

ping -M do -s 1400 -c 3 10.20.0.10

Se uma carga de 1400 bytes passar e 1472 não, o máximo do caminho é menor do que as aplicações esperam e encontrou uma regressão real, não cosmética. Compare esse resultado com os requisitos escritos no primeiro passo e retire o circuito só quando os proprietários dessas aplicações aceitarem a medição. É essa assinatura que transforma um teste bem-sucedido numa migração aceite.