Migrace VPN z IOS na ASA: překládejte dohodu, ne příkazy

Konfigurace IOS, která přichází jako reference pro migraci na ASA, popisuje dohodu zabalenou do syntaxe jedné platformy. Adresy protějšků, identity a chráněné rozsahy jsou dohoda. Kruh klíčů, profil a řetěz kryptomap jsou způsob, jakým to IOS vyjadřuje, zatímco ASA vyjadřuje stejný záměr pomocí tunelových skupin a jejich atributů. Kopírování druhé části nikdy nefunguje a kopírování jen první nechává práci napůl.

Projděte pět kroků níže v pořadí a zastavte se všude, kde obě platformy popisují různé věci, nikoli různá slova.

Krok 1: oddělte dohodu od syntaxe

Napište předání jako požadavky, na kterých se oba správci shodnou. Čtyři řádky pokrývají téměř vše: kde je protějšek a která strana iniciuje, jak každá strana prokazuje svou identitu, jaká ochrana je přijatelná a které aplikace musí tunelem projít. Žádný z těchto řádků nezmiňuje příkaz.

Uchovávejte původní text jako důkaz, ne jako instrukce. Řádek, který existuje na jedné platformě a na druhé ne, je rozdíl v syntaxi, dokud neověříte, zda lze stejný požadavek splnit jinak.

Krok 2: pojmenujte objekty na každé platformě

V IOS XE napájí kruh klíčů IKEv2 profil IKEv2 a tento profil se připojuje přes kryptomapu nebo profil IPsec. V ASA drží tunelová skupina profil připojení a jeho atributy IPsec a kryptomapa na ni ukazuje, jak popisuje průvodce profilem připojení to. Jsou to různé grafy objektů s různým dědictvím, a proto mapování řádek po řádku dává konfiguraci, která se parsuje, ale nepřipojí se.

Stavte cílové objekty z řádků požadavků, ne ze zdrojových řádků. Pokud jsou řádky úplné, je cílová konfigurace designovým rozhodnutím. Pokud nejsou, žádné množství překladu příkazů chybějící záměr nedodá.

Krok 3: přenášejte identitu, ne jen adresy

Identita je část, která se tiše láme. Protějšek, který se autentizuje adresou, se chová jinak než ten, který se autentizuje subjektem certifikátu nebo FQDN, a obě platformy zaznamenávají toto očekávání na různých místech. Zachovejte zamýšlenou identitu a řetěz důvěry místo toho, abyste nahradili sdílené tajemství, protože se to snáze testuje.

Držte předsdílené tajemství mimo srovnávací poznámky a tikety. Zapište, kdo ho vlastní a jak se pohybuje schváleným kanálem, a pamatujte, že zástupný symbol z dokumentačního příkladu není zákazníkovo pověření.

Krok 4: dohodněte ochranu před přepnutím

Nepřenášejte stará kryptografická nastavení jen proto, že se objevují v dodaném textu. Dohodněte průnik sad, které oba nasazené protějšky aktuálně podporují, a potvrďte ho s druhým správcem před oknem změny. Pokud se tento průnik liší od toho, co stávající protějšek očekává, je to koordinovaná změna, ne místní úprava.

Zapište dohodnutou sadu. Dva správci s různými vzpomínkami na telefonní hovor jsou důvod, proč přepnutí vyrobí neshodu druhé fáze.

Krok 5: ověřte službu, ne syntaxi

Nejprve zkontrolujte efektivní objekty cíle, potom přijatou asociaci, potom skutečný tok aplikace a jeho odpověď. Zadání příkazu bez chyby dokazuje syntaxi a nic jiného. Tunel, který se zvedne a nenese provoz, obvykle znamená, že chráněné rozsahy nebo zpětná trasa nesouhlasí s druhou stranou, což je problém řádku požadavků, ne příkazu. Porovnejte chráněné rozsahy na obou stranách, než znovu sáhnete na kryptomapu.

Zaznamenejte, co jste ověřili, se kterými adresami a z které strany. Tento záznam mění nejednoznačné tvrzení, že VPN běží, v něco, co druhý správce může nezávisle zkontrolovat.

Co vracet

Pošlete matici požadavků, shrnutí cílové konfigurace a výsledky ověření. Výslovně uveďte, která zdrojová nastavení jste nepřenesli a proč. Tento seznam je užitečnější než přeložená konfigurace, protože právě tam začne příští neshoda.

Uchovejte zdrojový text také u tiketu. Dokumentuje, co bylo požadováno, zatímco matice dokumentuje, na čem se dohodlo.