Migración de VPN de IOS a ASA: traduzca el acuerdo, no los comandos

Una configuración de IOS que llega como referencia para una migración a ASA describe un acuerdo envuelto en la sintaxis de una plataforma. Las direcciones de los pares, las identidades y los rangos protegidos son el acuerdo. El anillo de claves, el perfil y la cadena de mapas criptográficos son la forma en que IOS lo expresa, mientras que el ASA expresa la misma intención mediante grupos de túnel y sus atributos. Copiar la segunda parte nunca funciona, y copiar solo la primera deja el trabajo a medias.

Recorra los cinco pasos siguientes en orden y deténgase allí donde las dos plataformas describan cosas distintas y no palabras distintas.

Paso 1: separe el acuerdo de la sintaxis

Escriba el traspaso como requisitos en los que coincidan ambos administradores. Cuatro filas lo cubren casi todo: dónde está el par y qué lado inicia, cómo demuestra cada lado su identidad, qué protección es aceptable y qué aplicaciones deben sobrevivir al túnel. Ninguna de esas filas menciona un comando.

Conserve el texto original como prueba y no como instrucciones. Una línea que existe en una plataforma y no en la otra es una diferencia de sintaxis hasta que haya comprobado si el mismo requisito puede cumplirse de otra manera.

Paso 2: nombre los objetos en cada plataforma

En IOS XE un anillo de claves IKEv2 alimenta un perfil IKEv2, y ese perfil se adjunta mediante un mapa criptográfico o un perfil IPsec. En el ASA un grupo de túnel contiene el perfil de conexión y sus atributos IPsec, y el mapa criptográfico apunta a él, como describe la guía del perfil de conexión. Son gráficos de objetos distintos con herencia distinta, y por eso una correspondencia línea por línea produce una configuración que se analiza y no se conecta.

Construya los objetos de destino a partir de las filas de requisitos y no de las líneas de origen. Si las filas están completas, la configuración de destino es una decisión de diseño. Si no lo están, ninguna cantidad de traducción de comandos aportará la intención que falta.

Paso 3: lleve la identidad, no solo las direcciones

La identidad es la parte que se rompe en silencio. Un par que se autentica por dirección se comporta de forma distinta a uno que lo hace por el sujeto del certificado o por el FQDN, y las dos plataformas registran esa expectativa en lugares distintos. Preserve la identidad prevista y la cadena de confianza en lugar de sustituir un secreto compartido porque es más fácil de probar.

Mantenga el secreto precompartido fuera de las notas de comparación y de los tiques. Anote quién lo posee y cómo se mueve por un canal aprobado, y recuerde que un marcador de posición de un ejemplo de documentación no es la credencial del cliente.

Paso 4: acuerde la protección antes de la conmutación

No traslade ajustes criptográficos antiguos solo porque aparezcan en el texto suministrado. Acuerde una intersección de conjuntos que ambos pares desplegados admitan actualmente y confírmela con el otro administrador antes de la ventana de cambio. Si esa intersección difiere de lo que espera el par existente, es un cambio coordinado y no una edición local.

Escriba el conjunto acordado. Dos administradores con recuerdos distintos de una llamada telefónica es como una conmutación produce un desajuste de fase dos.

Paso 5: verifique el servicio, no la sintaxis

Compruebe primero los objetos efectivos del destino, después la asociación aceptada, después un flujo real de aplicación y su respuesta. Introducir un comando sin error demuestra la sintaxis y nada más. Un túnel que sube y no transporta tráfico suele significar que los rangos protegidos o la ruta de retorno no coinciden con el otro lado, lo que es un problema de fila de requisitos y no de comando. Compare los rangos protegidos en ambos lados antes de volver a tocar el mapa criptográfico.

Registre qué verificó, con qué direcciones y desde qué lado. Ese registro convierte una afirmación ambigua de que la VPN está activa en algo que el otro administrador puede comprobar de forma independiente.

Qué devolver

Envíe la matriz de requisitos, un resumen de la configuración de destino y los resultados de la verificación. Indique explícitamente qué ajustes de origen no trasladó y por qué. Esa lista es más útil que la configuración traducida, porque es donde empezará el siguiente desacuerdo.

Conserve también el texto de origen con el tique. Documenta lo que se pidió, mientras que la matriz documenta lo que se acordó.