En IOS-konfiguration, der ankommer som reference for en ASA-migrering, beskriver en aftale pakket ind i én platforms syntaks. Peer-adresser, identiteter og beskyttede områder er aftalen. Nøgleringen, profilen og kryptokortkæden er, hvordan IOS udtrykker det, mens ASA udtrykker den samme hensigt gennem tunnelgrupper og deres attributter. At kopiere den anden del virker aldrig, og at kopiere kun den første efterlader arbejdet halvt færdigt.

Gå gennem de fem trin nedenfor i rækkefølge, og stop, hvor de to platforme beskriver forskellige ting frem for forskellige ord.

Trin 1: adskil aftalen fra syntaksen

Skriv overdragelsen som krav, som begge administratorer er enige om. Fire rækker dækker næsten det hele: hvor peer er, og hvilken side der starter, hvordan hver side beviser sin identitet, hvilken beskyttelse der er acceptabel, og hvilke applikationer der skal overleve tunnelen. Ingen af disse rækker nævner en kommando.

Behold den oprindelige tekst som bevis frem for instruktioner. En linje, der findes på den ene platform og ikke på den anden, er en syntaksforskel, indtil du har undersøgt, om det samme krav kan opfyldes på en anden måde.

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

Trin 2: navngiv objekterne på hver platform

På IOS XE føder en IKEv2-nøglering en IKEv2-profil, og den profil vedhæftes via et kryptokort eller en IPsec-profil. På ASA holder en tunnelgruppe forbindelsesprofilen og dens IPsec-attributter, og kryptokortet peger på den, som vejledningen til forbindelsesprofilen beskriver. Det er forskellige objektgrafer med forskellig arv, og derfor giver en linje-for-linje-mapping en konfiguration, der parses og ikke forbindes.

Byg målobjekterne ud fra kravene, ikke ud fra kildelinjerne. Hvis rækkerne er komplette, er målkonfigurationen en designbeslutning. Hvis ikke, kan ingen mængde kommandooversættelse levere den manglende hensigt.

Trin 3: overfør identitet, ikke kun adresser

Identitet er den del, der brækker stille. En peer, der autentificerer via adresse, opfører sig anderledes end en, der autentificerer via certifikatets emne eller FQDN, og de to platforme registrerer den forventning forskellige steder. Bevar den tilsigtede identitet og tillidskæde i stedet for at erstatte en delt hemmelighed, fordi det er nemmere at teste.

Hold den foruddelte hemmelighed væk fra sammenligningsnoter og sager. Noter, hvem der ejer den, og hvordan den flyttes gennem en godkendt kanal, og husk, at en pladsholder fra et dokumentationseksempel ikke er kundens legitimationsoplysninger.

Trin 4: aftal beskyttelsen før skiftet

Overfør ikke gamle kryptografiske indstillinger, fordi de optræder i den leverede tekst. Aftal et fælles snit af suiter, som begge udrullede peers aktuelt understøtter, og bekræft det med den anden administrator før ændringsvinduet. Hvis dette snit afviger fra det, den eksisterende peer forventer, er det en koordineret ændring frem for en lokal redigering.

Skriv det aftalte sæt ned. To administratorer med forskellige erindringer om en telefonopringning er, hvordan et skifte giver en fase-to-uoverensstemmelse.

Trin 5: verificer tjenesten, ikke syntaksen

Kontroller først målets effektive objekter, derefter den accepterede association, derefter et rigtigt applikationsflow og dets svar. At indtaste en kommando uden fejl beviser syntaks og intet andet. En tunnel, der kommer op og ikke bærer trafik, betyder normalt, at beskyttede områder eller returruten ikke stemmer med den anden side, hvilket er et kravrækkeproblem frem for et kommandoproblem. Sammenlign de beskyttede områder på begge sider, før du rører kryptokortet igen.

Noter, hvad du verificerede, med hvilke adresser, fra hvilken side. Den registrering gør en tvetydig påstand om, at VPN er oppe, til noget, den anden administrator kan kontrollere uafhængigt.

Hvad du skal give tilbage

Send kravmatricen, et resumé af målkonfigurationen og verifikationsresultaterne. Angiv udtrykkeligt, hvilke kildeindstillinger du ikke overførte, og hvorfor. Den liste er mere nyttig end den oversatte konfiguration, fordi det er der, den næste uenighed begynder.

Behold også kildeteksten sammen med sagen. Den dokumenterer, hvad der blev bedt om, mens matricen dokumenterer, hvad der blev aftalt.

Relaterede artikler