Migrar unha subrede a un novo túnel VPN sen cortes
Mova todo o camiño dunha subrede: ruta, selectores, regras de acceso, tráfico de volta e reversión. Levante primeiro o túnel e despois faga o corte de forma estreita.
Levante o túnel novo, mova unha subrede e esa subrede agora falla de forma intermitente mentres todo o demais funciona perfectamente. As VPN migradas a medias fallan exactamente así, porque o túnel nunca foi a parte difícil. O camiño tamén inclúe que ruta gaña, que selectores coinciden, que permiten as regras de acceso, como volven as respostas e calquera tradución que aplicase o deseño antigo. Mova só o túnel e non terá movido nada diso.
O túnel é a metade fácil do camiño
Os fallos intermitentes tras unha migración parcial adoitan significar que dúas rutas son ambas plausibles. Algúns fluxos escollen o túnel novo, outros quedan co vello, e un dispositivo que lembra o estado ve entón chegar unha resposta por unha ruta que a petición nunca usou. Dúas rutas non son automaticamente máis seguras ca unha; son dúas cousas que poden discrepar. Mire os informes de oscilación e non os contadores do túnel, porque os contadores parecerán sans todo o tempo.
A primeira pregunta útil non é que túnel é mellor. É que fluxos escollen que ruta hoxe e se a petición e a resposta obteñen a mesma resposta.
Construa o destino antes de o preferir
Confirme que os pares son compatibles e que o túnel novo leva o ámbito de enderezos que pretende. Engada o reenvío e os permisos de servizo que necesita mentres segue sendo a ruta non preferida, para que o corte en si só cambie a selección e nada máis.
Pregunte ao sitio remoto como devolverá o tráfico. Se as respostas aínda saen polo túnel vello, unha ruta local nova produce asimetría ou falla nun filtro que lembra o estado. A tradución tamén pertence ao deseño polo mesmo motivo: un enderezo de orixe cambiado tamén cambia a ruta de volta.
Corte de forma estreita e coñeza o camiño de volta
Nomee a subrede exacta e o mecanismo soportado pola plataforma que prefire a súa ruta ou selector novo. As definicións baseadas en políticas non sempre se comportan como métricas de ruta, así que lea as regras de políticas solapadas da súa implementación antes de supoñer que gaña a coincidencia máis específica.
Mova unha subrede, non un sitio. Manteña o acceso de xestión nun camiño que non toque, e escriba a reversión antes de aplicar nada: que ruta ou política reverte, quen o fai e como seguen conectados mentres o fan.
Asimetría e estado obsoleto
As devasas e os dispositivos NAT lembran a interface que usou un fluxo. Cando a petición e a resposta toman túneles distintos, o dispositivo pode descartar a resposta aínda que cada camiño funcione por si só. Probe cun fluxo que abra despois do cambio, porque unha sesión establecida pode seguir usando a ruta vella durante horas.
Se o enderezo de orixe observado se moveu, atope cada política que nomee o vello. Unha migración que cambia a orixe en silencio rompe regras que ninguén clasificou como parte do deseño da VPN.
Demostre as dúas respostas e despois retire a política vella
Desde un host corrente na subrede migrada, chegue ao servizo previsto e comprobe a orixe observada e a interface de resposta. Despois probe unha rede que debe quedar no túnel vello, porque unha migración só remata cando as dúas respostas son correctas. A segunda proba é a que a xente salta, e é a que atrapa un selector máis amplo do que quería.
Retire a política obsoleta só cando ningunha subrede restante dependa dela, e rexistre a ruta final co seu dono no inventario de selectores. Rematar non é que o túnel novo informe que está arriba; é que cada rede siga a ruta que lle corresponde.