Que debe preservar unha migración a VPN dun circuíto privado
Un circuíto privado levaba direccionamento, latencia e promesas de soporte. Inventaríeos, encamiñe os dous sentidos e acepte o túnel primeiro con tráfico real.
Os circuítos privados son fáciles de describir e difíciles de substituír, porque o contrato cubría máis que un cable. Levaba unha entrega, un plan de enderezos, unha expectativa de latencia e un acordo de soporte, e o túnel que o substitúe herda os catro, os escribise alguén ou non. As migracións fallan cando o equipo copia a configuración de encamiñamento e chama ao resto un problema de operacións. Comece polos requisitos e despois demostre cada un na ruta nova antes de cancelar a anterior.
Converta o circuíto nunha lista de propiedades
A primeira pregunta é que entregou realmente o servizo antigo: unha ligazón encamiñada cunha subrede pequena ou un segmento de capa 2 compartido entre sedes. Esa distinción decide se un túnel IP pode reproducilo, porque un túnel transporta paquetes entre dous enderezos e non transporta descuberta por broadcast nin EtherTypes arbitrarios. Un circuíto que se presentaba como un porto de conmutador é unha migración distinta dun que presentaba unha /30.
Anote os prefixos de sede, os enderezos de porta de enlace, as aplicacións que incrustan enderezos na súa propia configuración e os prefixos que se solapan noutro lugar do contorno. Un plan de enderezos que sobreviva á migración é un resultado de deseño, non unha suposición. Esas catro listas tamén se converten despois en criterios de aceptación, así que gárdeas onde os probadores poidan lelas.
Encamiñe a ruta nova nos dous sentidos
Un túnel que sobe é só medio camiño. O lado remoto necesita unha ruta de volta a cada prefixo local, e o lado local debe preferir o túnel para eses prefixos sen roubar tráfico que aínda debe saír por internet. O reenvío asimétrico é o síntoma habitual de acertar unha desas metades. Revise a táboa do lado remoto co mesmo coidado que a súa, porque a ruta de volta é a que ninguén configurou.
ip route get 10.20.0.10O encamiñamento por políticas fai explícita a división: marque o tráfico que pertence ao par de sedes e déalle unha táboa cuxo valor por defecto sexa o túnel. IPsec fornece a asociación protexida e a política que decide que entra nela, pero non as rutas ao seu redor, como a arquitectura IPsec describe. Cando a marca coincide demasiado amplamente, o tráfico web ordinario da sede tamén entra no túnel e sae pola saída equivocada.
Cambie cunha reversión que xa probou
Dúas rutas vivas con propietarios distintos invitan ao reenvío asimétrico, así que levante a nova dentro dunha xanela definida e mova os prefixos nunha orde declarada. Manteña o circuíto antigo configurado e conserve unha vía de xestión fóra de banda que non dependa de ningún dos dous túneles. Mova un prefixo cada vez onde as aplicacións o permitan e observe a táboa de sesións entre movementos.
Decida de antemán que probas autorizan o cambio e que condición desencadea a reversión. Unha reversión que require reparar o VPN novo a través da conexión fallida non é unha reversión. Enuncie o desencadeante como unha condición medible e non como unha sensación na sala.
Acepte co tráfico que o circuíto levaba realmente
Ping demostra alcanzabilidade e pouco máis. Probe a resolución de nomes, as sesións de longa duración, os fluxos denegados e os tamaños de paquete que a ruta antiga manexaba sen fragmentación. A MTU é onde os túneles máis a miúdo difiren dun circuíto, porque a encapsulación consume bytes que a aplicación daba por dispoñibles. Mida a carga útil máis grande que pasa sen fragmentación nos dous sentidos, non só cara ao servidor.
ping -M do -s 1400 -c 3 10.20.0.10Se unha carga de 1400 bytes pasa e 1472 non, o máximo da ruta é menor do que as aplicacións esperan e atopou unha regresión real, non cosmética. Compare ese resultado cos requisitos escritos no primeiro paso e retire o circuíto só cando os propietarios desas aplicacións acepten a medición. Esa sinatura é o que converte unha proba exitosa nunha migración aceptada.