Migración de VPN de IOS a ASA: traduza o acordo, non as ordes
Un mapa criptográfico non é un grupo de túnel de ASA. Que partes do acordo se transfiren, cales hai que reconstruír e as comprobacións que demostran que o servizo funciona.
Unha configuración de IOS que chega como referencia para unha migración a ASA describe un acordo envolto na sintaxe dunha plataforma. Os enderezos dos pares, as identidades e os rangos protexidos son o acordo. O anel de chaves, o perfil e a cadea de mapas criptográficos son a forma en que IOS o expresa, mentres que o ASA expresa a mesma intención mediante grupos de túnel e os seus atributos. Copiar a segunda parte nunca funciona, e copiar só a primeira deixa o traballo a medias.
Percorra os cinco pasos seguintes en orde e detéñase alí onde as dúas plataformas describan cousas distintas e non palabras distintas.
Paso 1: separe o acordo da sintaxe
Escriba a transferencia como requisitos nos que coincidan ambos administradores. Catro filas cobren case todo: onde está o par e que lado inicia, como demostra cada lado a súa identidade, que protección é aceptable e que aplicacións deben sobrevivir ao túnel. Ningunha desas filas menciona unha orde.
Conserve o texto orixinal como proba e non como instrucións. Unha liña que existe nunha plataforma e non na outra é unha diferenza de sintaxe ata que comprobe se o mesmo requisito se pode cumprir doutro xeito.
| Requirement | What must be agreed |
|---|---|
| Peer delivery | Outer endpoint, address family, NAT view, initiating side |
| Authentication | IKE version, expected identities, credential method and delivery |
| Data protection | Permitted suites, protected ranges, intentional translation |
| Application | Routes, return routes, resources beyond the tunnel |
Paso 2: nomee os obxectos en cada plataforma
En IOS XE un anel de chaves IKEv2 alimenta un perfil IKEv2, e ese perfil adxúntase mediante un mapa criptográfico ou un perfil IPsec. No ASA un grupo de túnel contén o perfil de conexión e os seus atributos IPsec, e o mapa criptográfico apunta a el, como describe a guía do perfil de conexión. Son gráficos de obxectos distintos con herdanza distinta, e por iso unha correspondencia liña por liña produce unha configuración que se analiza e non se conecta.
Construíde os obxectos de destino a partir das filas de requisitos e non das liñas de orixe. Se as filas están completas, a configuración de destino é unha decisión de deseño. Se non o están, ningunha cantidade de tradución de ordes achegará a intención que falta.
Paso 3: leve a identidade, non só os enderezos
A identidade é a parte que se rompe en silencio. Un par que se autentica por enderezo compórtase de forma distinta a un que o fai polo suxeito do certificado ou polo FQDN, e as dúas plataformas rexistran esa expectativa en lugares distintos. Preserve a identidade prevista e a cadea de confianza en lugar de substituír un segredo compartido porque é máis fácil de probar.
Manteña o segredo precompartido fóra das notas de comparación e dos tíckets. Anote quen o posúe e como se move por unha canle aprobada, e lembre que un marcador de posición dun exemplo de documentación non é a credencial do cliente.
Paso 4: acorde a protección antes da conmutación
Non traslade axustes criptográficos antigos só porque aparezan no texto subministrado. Acorde unha intersección de conxuntos que ambos pares despregados admitan actualmente e confírmea co outro administrador antes da xanela de cambio. Se esa intersección difire do que espera o par existente, é un cambio coordinado e non unha edición local.
Escriba o conxunto acordado. Dous administradores con recordos distintos dunha chamada telefónica é como unha conmutación produce un desaxuste de fase dous.
Paso 5: verifique o servizo, non a sintaxe
Comprobe primeiro os obxectos efectivos do destino, despois a asociación aceptada, despois un fluxo real de aplicación e a súa resposta. Introducir unha orde sen erro demostra a sintaxe e nada máis. Un túnel que sobe e non transporta tráfico normalmente significa que os rangos protexidos ou a ruta de retorno non coinciden co outro lado, o que é un problema de fila de requisitos e non de orde. Compare os rangos protexidos nos dous lados antes de volver tocar o mapa criptográfico.
Rexiste que verificou, con que enderezos e desde que lado. Ese rexistro converte unha afirmación ambigua de que a VPN está activa en algo que o outro administrador pode comprobar de forma independente.
Que devolver
Envíe a matriz de requisitos, un resumo da configuración de destino e os resultados da verificación. Indique explicitamente que axustes de orixe non trasladou e por que. Esa lista é máis útil que a configuración traducida, porque é onde comezará o seguinte desacordo.
Conserve tamén o texto de orixe co tícket. Documenta o que se pediu, mentres que a matriz documenta o que se acordou.