Una configuració d'IOS que arriba com a referència per a una migració a ASA descriu un acord embolicat en la sintaxi d'una plataforma. Les adreces dels parells, les identitats i els rangs protegits són l'acord. L'anell de claus, el perfil i la cadena de mapes criptogràfics són com ho expressa IOS, mentre que l'ASA expressa la mateixa intenció mitjançant grups de túnel i els seus atributs. Copiar la segona part no funciona mai, i copiar només la primera deixa la feina a mitges.

Recorreu els cinc passos següents en ordre i atureu-vos allà on les dues plataformes descriguin coses diferents i no paraules diferents.

Pas 1: separeu l'acord de la sintaxi

Escriviu el traspàs com a requisits en què coincideixin els dos administradors. Quatre files ho cobreixen gairebé tot: on és el parell i quin costat inicia, com demostra cada costat la seva identitat, quina protecció és acceptable i quines aplicacions han de sobreviure al túnel. Cap d'aquestes files no esmenta una ordre.

Conserveu el text original com a prova i no com a instruccions. Una línia que existeix en una plataforma i no en l'altra és una diferència de sintaxi fins que hàgiu comprovat si el mateix requisit es pot satisfer d'una altra manera.

RequirementWhat must be agreed
Peer deliveryOuter endpoint, address family, NAT view, initiating side
AuthenticationIKE version, expected identities, credential method and delivery
Data protectionPermitted suites, protected ranges, intentional translation
ApplicationRoutes, return routes, resources beyond the tunnel

Pas 2: anomeneu els objectes de cada plataforma

A IOS XE un anell de claus IKEv2 alimenta un perfil IKEv2, i aquest perfil s'adjunta mitjançant un mapa criptogràfic o un perfil IPsec. A l'ASA un grup de túnel conté el perfil de connexió i els seus atributs IPsec, i el mapa criptogràfic hi apunta, tal com descriu la guia del perfil de connexió. Són gràfics d'objectes diferents amb herència diferent, i per això una correspondència línia per línia produeix una configuració que s'analitza i no es connecta.

Construïu els objectes de destí a partir de les files de requisits i no de les línies d'origen. Si les files són completes, la configuració de destí és una decisió de disseny. Si no ho són, cap quantitat de traducció d'ordres no aportarà la intenció que falta.

Pas 3: porteu la identitat, no només les adreces

La identitat és la part que es trenca en silenci. Un parell que s'autentica per adreça es comporta de manera diferent d'un que ho fa pel subjecte del certificat o per l'FQDN, i les dues plataformes enregistren aquesta expectativa en llocs diferents. Preserveu la identitat prevista i la cadena de confiança en lloc de substituir un secret compartit perquè és més fàcil de provar.

Mantingueu el secret precompartit fora de les notes de comparació i dels tiquets. Anoteu qui en és el propietari i com es mou per un canal aprovat, i recordeu que un marcador d'un exemple de documentació no és la credencial del client.

Pas 4: acordeu la protecció abans de la commutació

No traslladeu paràmetres criptogràfics antics només perquè apareixen al text subministrat. Acordeu una intersecció de conjunts que els dos parells desplegats admetin actualment i confirmeu-ho amb l'altre administrador abans de la finestra de canvi. Si aquesta intersecció difereix del que espera el parell existent, és un canvi coordinat i no una edició local.

Escriviu el conjunt acordat. Dos administradors amb records diferents d'una trucada telefònica és com una commutació produeix un desajust de fase dos.

Pas 5: verifiqueu el servei, no la sintaxi

Comproveu primer els objectes efectius del destí, després l'associació acceptada, després un flux real d'aplicació i la seva resposta. Introduir una ordre sense error demostra la sintaxi i res més. Un túnel que s'aixeca i no transporta trànsit normalment vol dir que els rangs protegits o la ruta de retorn no coincideixen amb l'altre costat, cosa que és un problema de fila de requisits i no d'ordre. Compareu els rangs protegits dels dos costats abans de tornar a tocar el mapa criptogràfic.

Enregistreu què heu verificat, amb quines adreces i des de quin costat. Aquest registre converteix una afirmació ambigua que la VPN funciona en una cosa que l'altre administrador pot comprovar de manera independent.

Què cal retornar

Envieu la matriu de requisits, un resum de la configuració de destí i els resultats de la verificació. Digueu explícitament quins paràmetres d'origen no heu traslladat i per què. Aquesta llista és més útil que la configuració traduïda, perquè és on començarà el proper desacord.

Conserveu també el text d'origen amb el tiquet. Documenta què es va demanar, mentre que la matriu documenta què es va acordar.

Articles relacionats