IOS-naar-ASA VPN-migratie: vertaal de afspraak, niet de CLI
Een crypto map is geen ASA tunnel-group. Welke delen van de afspraak overgaan, welke opnieuw moeten worden opgebouwd, en de controles die bewijzen dat de dienst werkt.
Een IOS-configuratie die als referentie voor een ASA-migratie binnenkomt, beschrijft een afspraak verpakt in de syntaxis van één platform. Peeradressen, identiteiten en beschermde bereiken zijn de afspraak. De key ring, het profiel en de crypto map-keten is hoe IOS die uitdrukt, terwijl de ASA dezelfde bedoeling uitdrukt via tunnel groups en hun attributen. Het tweede deel kopiëren werkt nooit, en alleen het eerste kopiëren laat de klus half af.
Werk de vijf stappen hieronder in volgorde door, en stop waar de twee platforms verschillende dingen beschrijven in plaats van verschillende woorden.
Stap 1: scheid de afspraak van de syntaxis
Schrijf de overdracht als eisen waar beide beheerders het over eens zijn. Vier rijen dekken bijna alles: waar de peer is en welke kant initieert, hoe elke kant zijn identiteit bewijst, welke bescherming aanvaardbaar is, en welke toepassingen de tunnel moeten overleven. Geen van die rijen noemt een commando.
Bewaar de originele tekst als bewijs, niet als instructie. Een regel die op het ene platform bestaat en op het andere niet, is een syntaxisverschil tot je hebt gecontroleerd of dezelfde eis op een andere manier kan worden vervuld.
| 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 |
Stap 2: benoem de objecten op elk platform
Op IOS XE voedt een IKEv2 key ring een IKEv2-profiel, en dat profiel wordt gekoppeld via een crypto map of een IPsec-profiel. Op de ASA bevat een tunnel group het connection profile en de IPsec-attributen, en de crypto map verwijst ernaar, zoals de handleiding voor connection profiles beschrijft. Dat zijn verschillende objectgrafen met verschillende overerving, en daarom levert een regel-voor-regel-koppeling een configuratie op die parseert en niet verbindt.
Bouw de doelobjecten vanuit de eisenrijen in plaats van vanuit de bronregels. Als de rijen compleet zijn, is de doelconfiguratie een ontwerpbeslissing. Als ze dat niet zijn, levert geen enkele hoeveelheid commandovertaling de ontbrekende bedoeling.
Stap 3: draag identiteit, niet alleen adressen
Identiteit is het deel dat stilletjes breekt. Een peer die op adres authenticeert, gedraagt zich anders dan een die op certificaatonderwerp of FQDN authenticeert, en de twee platforms leggen die verwachting op verschillende plaatsen vast. Behoud de bedoelde identiteit en vertrouwensketen in plaats van een gedeeld geheim in te vullen omdat dat makkelijker te testen is.
Houd het vooraf gedeelde geheim buiten vergelijkingsnotities en tickets. Leg vast wie het bezit en hoe het via een goedgekeurd kanaal beweegt, en onthoud dat een plaatsaanduiding uit een documentatievoorbeeld niet de inloggegevens van de klant zijn.
Stap 4: spreek de bescherming af vóór de cutover
Neem oude cryptografische instellingen niet over omdat ze in de aangeleverde tekst staan. Spreek een doorsnede van suites af die beide geïmplementeerde peers nu ondersteunen, en bevestig die met de andere beheerder vóór het wijzigingsvenster. Als die doorsnede afwijkt van wat de bestaande peer verwacht, is het een gecoördineerde wijziging en geen lokale aanpassing.
Schrijf de afgesproken set op. Twee beheerders met verschillende herinneringen aan een telefoongesprek is hoe een cutover een fase-twee-mismatch oplevert.
Stap 5: verifieer de dienst, niet de syntaxis
Controleer eerst de effectieve objecten van het doel, dan de geaccepteerde associatie, dan een echte toepassingsstroom en het antwoord. Een commando zonder fout invoeren bewijst syntaxis en niets anders. Een tunnel die opkomt en geen verkeer draagt, betekent meestal dat beschermde bereiken of de retourroute het oneens zijn met de andere kant, wat een eisenrijprobleem is en geen commandoprobleem. Vergelijk de beschermde bereiken aan beide kanten voordat je de crypto map opnieuw aanraakt.
Leg vast wat je hebt geverifieerd, met welke adressen, vanaf welke kant. Dat verslag maakt van een dubbelzinnige bewering dat de VPN actief is iets wat de andere beheerder onafhankelijk kan controleren.
Wat je teruggeeft
Stuur de eisenmatrix, een samenvatting van de doelconfiguratie en de verificatieresultaten. Vermeld expliciet welke broninstellingen je niet hebt overgenomen en waarom. Die lijst is nuttiger dan de vertaalde configuratie, want daar begint de volgende onenigheid.
Bewaar ook de brontekst bij het ticket. Die documenteert wat er is gevraagd, terwijl de matrix documenteert wat er is afgesproken.