IOS-til-ASA VPN-migrering: omset avtalen, ikkje CLI-en
Eit crypto map er ikkje ei ASA tunnel-group. Kva delar av avtalen som blir overførte, kva som må byggjast på nytt, og kontrollane som provar at tenesta verkar.
Ein IOS-konfigurasjon som kjem som referanse for ei ASA-migrering, skildrar ein avtale pakka inn i syntaksen til éin plattform. Peer-adresser, identitetar og verna område er avtalen. Key ring, profil og crypto map-kjeda er korleis IOS uttrykkjer han, medan ASA uttrykkjer same intensjon gjennom tunnel groups og attributta deira. Å kopiere den andre delen fungerer aldri, og å kopiere berre den første lèt jobben vere halvferdig.
Arbeid deg gjennom dei fem trinna nedanfor i rekkefølgje, og stopp der dei to plattformene skildrar ulike ting snarare enn ulike ord.
Trinn 1: skil avtalen frå syntaksen
Skriv overleveringa som krav begge administratorane er samde om. Fire rader dekkjer nesten alt: kvar peeren er og kva side som startar, korleis kvar side provar identiteten sin, kva vern som er akseptabelt, og kva applikasjonar som må overleve tunnelen. Ingen av radene nemner ein kommando.
Hald på originalteksten som prov, ikkje som instruksjonar. Ei linje som finst på éi plattform og ikkje på den andre, er ein syntaksskilnad til du har sjekka om same krav kan oppfyllast på ein annan måte.
| 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 |
Trinn 2: namnset objekta på kvar plattform
På IOS XE matar ein IKEv2 key ring ein IKEv2-profil, og den profilen blir fest gjennom eit crypto map eller ein IPsec-profil. På ASA held ei tunnel group tilkoplingsprofilen og IPsec-attributta hans, og crypto map peikar på henne, slik rettleiinga for tilkoplingsprofilar skildrar. Det er ulike objektgrafar med ulik arv, og difor gjev ei linje-for-linje-kartlegging ein konfigurasjon som blir parsa og ikkje koplar til.
Bygg målobjekta frå kravradene i staden for frå kjeldelinjene. Viss radene er komplette, er målkonfigurasjonen ein designavgjerd. Viss dei ikkje er det, vil inga mengd kommandoomsetjing skaffe den manglande intensjonen.
Trinn 3: ber identitet, ikkje berre adresser
Identitet er delen som bryt stille. Ein peer som autentiserer etter adresse, oppfører seg annleis enn ein som autentiserer etter certifikatsubjekt eller FQDN, og dei to plattformene registrerer forventninga på ulike stader. Bevar den tiltenkte identiteten og tillitskjeda i staden for å setje inn ein delt løyndom fordi det er lettare å teste.
Hald den førehandsdelte løyndommen utanfor samanlikningsnotat og saker. Registrer kven som eig han og korleis han flyttar seg gjennom ein godkjend kanal, og hugs at ein plasshaldar frå eit dokumentasjonseksempel ikkje er kunden sin legitimasjon.
Trinn 4: bli samde om vernet før overgangen
Ikkje før gamle kryptografiske innstillingar vidare fordi dei står i den leverte teksten. Bli samde om eit snitt av suitar som begge utplasserte peers støttar i dag, og stadfest det med den andre administratoren før endringsvindauget. Viss snittet avvik frå det den eksisterande peeren ventar, er det ei koordinert endring og ikkje ei lokal redigering.
Skriv ned det avtalte settet. To administratorar med ulike minne om ein telefonsamtale er korleis ein overgang produserer ein fase-to-mismatch.
Trinn 5: verifiser tenesta, ikkje syntaksen
Sjekk dei effektive objekta til målet først, deretter den aksepterte assosiasjonen, så ein reell applikasjonsflyt og svaret. Å taste ein kommando utan feil provar syntaks og ingenting anna. Ein tunnel som kjem opp og ikkje ber trafikk, tyder vanlegvis at verna område eller returruta er usamde med den andre sida, som er eit kravradproblem og ikkje eit kommandepproblem. Samanlikn dei verna områda på begge sider før du rører crypto map igjen.
Registrer kva du verifiserte, med kva adresser, frå kva side. Den registreringa gjer ein tvitydig påstand om at VPN-en er oppe til noko den andre administratoren kan sjekke uavhengig.
Kva du skal levere tilbake
Send kravmatrisa, eit samandrag av målkonfigurasjonen og verifiseringsresultata. Sei eksplisitt kva kjeldeinnstillingar du ikkje førte vidare og kvifor. Den lista er nyttigare enn den omsette konfigurasjonen, fordi det er der neste usemje startar.
Hald òg kjeldeteksten i saka. Han dokumenterer kva som vart bedt om, medan matrisa dokumenterer kva som vart avtalt.