Migrar una subxarxa a un túnel VPN nou sense interrupcions

Aixequem el túnel nou, moveu una subxarxa i ara aquesta subxarxa falla de manera intermitent mentre tota la resta funciona perfectament. Les VPN migrades a mitges fallen exactament així, perquè el túnel mai no va ser la part difícil. El camí també inclou quina ruta guanya, quins selectors coincideixen, què permeten les regles d'accés, com tornen les respostes i qualsevol traducció que apliqués el disseny antic. Moveu només el túnel i no haureu mogut res d'això.

El túnel és la meitat fàcil del camí

Els errors intermitents després d'una migració parcial normalment volen dir que dos camins són tots dos plausibles. Alguns fluxos trien el túnel nou, d'altres es queden amb el vell, i un dispositiu que recorda l'estat veu arribar una resposta per un camí que la petició no va fer servir mai. Dos camins no són automàticament més segurs que un; són dues coses que poden discrepar. Mireu els informes d'oscil·lació i no els comptadors del túnel, perquè els comptadors semblaran sans tot el temps.

La primera pregunta útil no és quin túnel és millor. És quins fluxos trien quin camí avui i si la petició i la resposta obtenen la mateixa resposta.

Construïu la destinació abans de preferir-la

Confirmeu que els iguals són compatibles i que el túnel nou porta l'abast d'adreces que voleu. Afegiu-hi el reenviament i els permisos de servei que necessita mentre encara és el camí no preferit, perquè el canvi en si només canviï la selecció i res més.

Pregunteu al lloc remot com tornarà el trànsit. Si les respostes encara surten pel túnel vell, una ruta local nova produeix asimetria o falla en un filtre que recorda l'estat. La traducció també pertany al disseny pel mateix motiu: una adreça d'origen canviada també canvia el camí de tornada.

Feu el canvi de manera estreta i conegueu el camí de tornada

Anomeneu la subxarxa exacta i el mecanisme suportat per la plataforma que prefereix la seva ruta o selector nou. Les definicions basades en polítiques no sempre es comporten com les mètriques de ruta, així que llegiu les regles de polítiques solapades de la vostra implementació abans de suposar que guanya la coincidència més específica.

Moveu una subxarxa, no un lloc. Mantingueu l'accés de gestió en un camí que no toqueu i escriviu la reversió abans d'aplicar res: quina ruta o política reverteix, qui ho fa i com es mantenen connectats mentre ho fan.

Asimetria i estat caducat

Els tallafocs i els dispositius NAT recorden la interfície que va fer servir un flux. Quan la petició i la resposta prenen túnels diferents, el dispositiu pot descartar la resposta encara que cada camí funcioni sol. Proveu-ho amb un flux que obriu després del canvi, perquè una sessió establerta pot continuar fent servir el camí vell durant hores.

Si l'adreça d'origen observada s'ha mogut, trobeu cada política que n'anomena la vella. Una migració que canvia l'origen en silenci trenca regles que ningú no va classificar com a part del disseny de la VPN.

Demostreu les dues respostes i després retireu la política vella

Des d'un amfitrió corrent a la subxarxa migrada, arribeu al servei previst i comproveu l'origen observat i la interfície de resposta. Després proveu una xarxa que ha de romandre al túnel vell, perquè una migració només s'acaba quan les dues respostes són correctes. La segona prova és la que la gent s'estalvia, i és la que atrapa un selector més ampli del que volíeu.

Retireu la política obsoleta només quan cap subxarxa restant no en depengui, i registreu la ruta final amb el seu propietari a l'inventari de selectors. Acabar no és que el túnel nou reporti que està aixecat; és que cada xarxa segueixi el camí que li toca.