Migrar uma sub-rede para um novo túnel VPN sem interrupção

Suba o novo túnel, mova uma sub-rede, e essa sub-rede agora falha de forma intermitente enquanto todo o resto funciona perfeitamente. VPNs migradas pela metade falham exatamente assim, porque o túnel nunca foi a parte difícil. O caminho também inclui qual rota vence, quais seletores correspondem, o que as regras de acesso permitem, como as respostas voltam e qualquer tradução que o desenho antigo aplicasse. Mova só o túnel e não terá movido nada disso.

O túnel é a metade fácil do caminho

Falhas intermitentes após uma migração parcial normalmente significam que dois caminhos são ambos plausíveis. Alguns fluxos escolhem o túnel novo, outros ficam no antigo, e um dispositivo que guarda estado vê então uma resposta chegar por um caminho que o pedido nunca usou. Dois caminhos não são automaticamente mais seguros que um; são duas coisas que podem discordar. Olhe os relatórios de oscilação e não os contadores do túnel, porque os contadores parecerão saudáveis o tempo todo.

A primeira pergunta útil não é qual túnel é melhor. É quais fluxos escolhem qual caminho hoje, e se o pedido e a resposta recebem a mesma resposta.

Construa o destino antes de o preferir

Confirme que os pares são compatíveis e que o túnel novo leva o âmbito de endereços pretendido. Acrescente o encaminhamento e as permissões de serviço de que precisa enquanto ainda é o caminho não preferido, para que o corte em si mude apenas a seleção e nada mais.

Pergunte ao site remoto como devolverá o tráfego. Se as respostas ainda saírem pelo túnel antigo, uma nova rota local produz assimetria ou falha num filtro que guarda estado. A tradução também pertence ao desenho pelo mesmo motivo: um endereço de origem alterado também altera o caminho de volta.

Corte de forma estreita e saiba o caminho de volta

Nomeie a sub-rede exata e o mecanismo suportado pela plataforma que prefere a sua nova rota ou seletor. Definições baseadas em políticas nem sempre se comportam como métricas de rota, por isso leia as regras de políticas sobrepostas da sua implementação antes de assumir que ganha a correspondência mais específica.

Mova uma sub-rede, não um site. Mantenha o acesso de gestão num caminho que não toca, e escreva a reversão antes de aplicar qualquer coisa: qual rota ou política reverte, quem o faz e como permanecem ligados enquanto o fazem.

Assimetria e estado obsoleto

Firewalls e dispositivos NAT lembram a interface que um fluxo usou. Quando o pedido e a resposta tomam túneis diferentes, o dispositivo pode descartar a resposta mesmo que cada caminho funcione sozinho. Teste com um fluxo que abra depois da mudança, porque uma sessão estabelecida pode continuar a usar o caminho antigo durante horas.

Se o endereço de origem observado se deslocou, encontre cada política que nomeie o antigo. Uma migração que muda a origem em silêncio quebra regras que ninguém classificou como parte do desenho da VPN.

Prove as duas respostas e depois retire a política antiga

A partir de um host comum na sub-rede migrada, chegue ao serviço pretendido e verifique a origem observada e a interface de resposta. Depois teste uma rede que deve ficar no túnel antigo, porque uma migração só termina quando ambas as respostas estão certas. O segundo teste é o que as pessoas saltam, e é o que apanha um seletor mais amplo do que queria.

Retire a política obsoleta só quando nenhuma sub-rede restante depender dela, e registe a rota final com o seu dono no inventário de seletores. Terminar não é o túnel novo informar que está no ar; é cada rede seguir o caminho que lhe corresponde.