IOS-til-ASA VPN-migrering: oversett avtalen, ikke CLI-en
Et crypto map er ikke en ASA tunnel-group. Hvilke deler av avtalen som overføres, hvilke som må bygges på nytt, og kontrollene som beviser at tjenesten virker.
En IOS-konfigurasjon som kommer som referanse for en ASA-migrering, beskriver en avtale pakket inn i én plattforms syntaks. Peer-adresser, identiteter og beskyttede områder er avtalen. Key ring, profil og crypto map-kjeden er hvordan IOS uttrykker den, mens ASA uttrykker samme intensjon gjennom tunnel groups og deres attributter. Å kopiere den andre delen fungerer aldri, og å kopiere bare den første lar jobben være halvferdig.
Arbeid deg gjennom de fem trinnene nedenfor i rekkefølge, og stopp der de to plattformene beskriver forskjellige ting snarere enn forskjellige ord.
Trinn 1: skill avtalen fra syntaksen
Skriv overleveringen som krav begge administratorer er enige om. Fire rader dekker nesten alt: hvor peeren er og hvilken side som starter, hvordan hver side beviser identiteten sin, hvilken beskyttelse som er akseptabel, og hvilke applikasjoner som må overleve tunnelen. Ingen av radene nevner en kommando.
Behold originalteksten som bevis, ikke som instruksjoner. En linje som finnes på én plattform og ikke den andre, er en syntaksforskjell til du har sjekket om samme krav kan oppfylles på en annen 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: navngi objektene på hver plattform
På IOS XE mater en IKEv2 key ring en IKEv2-profil, og den profilen festes gjennom et crypto map eller en IPsec-profil. På ASA holder en tunnel group tilkoblingsprofilen og dens IPsec-attributter, og crypto map peker på den, slik veiledningen for tilkoblingsprofiler beskriver. Det er forskjellige objektgrafer med forskjellig arv, og derfor gir en linje-for-linje-kartlegging en konfigurasjon som parses og ikke kobler til.
Bygg målobjektene fra kravradene i stedet for fra kildelinjene. Hvis radene er komplette, er målkonfigurasjonen en designbeslutning. Hvis de ikke er det, vil ingen mengde kommandooversettelse skaffe den manglende intensjonen.
Trinn 3: bær identitet, ikke bare adresser
Identitet er delen som brytes stille. En peer som autentiserer etter adresse, oppfører seg annerledes enn en som autentiserer etter certifikatsubjekt eller FQDN, og de to plattformene registrerer forventningen på forskjellige steder. Bevar den tiltenkte identiteten og tillitskjeden i stedet for å sette inn en delt hemmelighet fordi det er lettere å teste.
Hold den forhåndsdelt hemmeligheten utenfor sammenligningsnotater og saker. Registrer hvem som eier den og hvordan den flyttes gjennom en godkjent kanal, og husk at en plassholder fra et dokumentasjonseksempel ikke er kundens legitimasjon.
Trinn 4: bli enige om beskyttelsen før overgangen
Ikke før gamle kryptografiske innstillinger videre fordi de står i den leverte teksten. Bli enige om et snitt av suiter som begge utplasserte peers støtter i dag, og bekreft det med den andre administratoren før endringsvinduet. Hvis snittet avviker fra det det eksisterende peeren forventer, er det en koordinert endring og ikke en lokal redigering.
Skriv ned det avtalte settet. To administratorer med forskjellige minner om en telefonsamtale er hvordan en overgang produserer en fase-to-mismatch.
Trinn 5: verifiser tjenesten, ikke syntaksen
Sjekk målets effektive objekter først, deretter den aksepterte assosiasjonen, så en reell applikasjonsflyt og svaret. Å taste en kommando uten feil beviser syntaks og ingenting annet. En tunnel som kommer opp og ikke bærer trafikk, betyr vanligvis at beskyttede områder eller returruten er uenige med den andre siden, som er et kravradproblem og ikke et kommandopproblem. Sammenlign de beskyttede områdene på begge sider før du rører crypto map igjen.
Registrer hva du verifiserte, med hvilke adresser, fra hvilken side. Den registreringen gjør en tvetydig påstand om at VPN-en er oppe til noe den andre administratoren kan sjekke uavhengig.
Hva du skal levere tilbake
Send kravmatrisen, et sammendrag av målkonfigurasjonen og verifiseringsresultatene. Si eksplisitt hvilke kildeinnstillinger du ikke førte videre og hvorfor. Den listen er nyttigere enn den oversatte konfigurasjonen, fordi det er der neste uenighet starter.
Behold også kildeteksten i saken. Den dokumenterer hva som ble bedt om, mens matrisen dokumenterer hva som ble avtalt.