Migrácia VPN z IOS na ASA: preložte dohodu, nie CLI

Konfigurácia IOS, ktorá prichádza ako referencia pre migráciu na ASA, opisuje dohodu zabalenú do syntaxe jednej platformy. Adresy protistrany, identity a chránené rozsahy sú dohodou. Kruh kľúčov, profil a reťaz crypto map sú spôsob, akým to vyjadruje IOS, kým ASA vyjadruje rovnaký zámer cez tunnel group a ich atribúty. Kopírovanie druhej časti nikdy nefunguje a kopírovanie iba prvej necháva prácu na polovicu.

Prejdite päť krokov nižšie v poradí a zastavte sa všade, kde dve platformy opisujú rozdielne veci, nie rozdielne slová.

Krok 1: oddeľte dohodu od syntaxe

Napíšte odovzdanie ako požiadavky, na ktorých sa zhodnú obaja administrátori. Štyri riadky pokrývajú takmer všetko: kde je protistrana a ktorá strana iniciuje, ako každá strana preukazuje svoju identitu, aká ochrana je prijateľná a ktoré aplikácie musia prežiť tunel. Ani jeden z tých riadkov nespomína príkaz.

Ponechajte pôvodný text ako dôkaz, nie ako pokyn. Riadok, ktorý existuje na jednej platforme a nie na druhej, je rozdiel v syntaxi, kým neoveríte, či sa tá istá požiadavka dá splniť inak.

Krok 2: pomenujte objekty na každej platforme

Na IOS XE kruh kľúčov IKEv2 napája profil IKEv2 a ten profil sa pripája cez crypto map alebo profil IPsec. Na ASA tunnel group drží profil pripojenia a jeho atribúty IPsec a crypto map naň ukazuje, ako opisuje sprievodca profilom pripojenia. Sú to rozdielne grafy objektov s rozdielnym dedením, preto mapovanie riadok po riadku dáva konfiguráciu, ktorá sa parsuje a nepripojí sa.

Stavajte cieľové objekty z riadkov požiadaviek, nie zo zdrojových riadkov. Ak sú riadky úplné, cieľová konfigurácia je dizajnové rozhodnutie. Ak nie sú, žiadne množstvo prekladu príkazov nedodá chýbajúci zámer.

Krok 3: preneste identitu, nielen adresy

Identita je časť, ktorá sa ticho pokazí. Protistrana, ktorá sa autentizuje adresou, sa správa inak než tá, ktorá sa autentizuje subjektom certifikátu alebo FQDN, a obe platformy zaznamenávajú toto očakávanie na rozdielnych miestach. Zachovajte zamýšľanú identitu a reťaz dôvery namiesto nahradenia zdieľaného tajomstva preto, že sa ľahšie testuje.

Držte zdieľané tajomstvo mimo porovnávacích poznámok a tiketov. Zaznamenajte, kto ho vlastní a ako sa pohybuje schváleným kanálom, a pamätajte, že zástupný symbol z príkladu v dokumentácii nie je poverenie zákazníka.

Krok 4: dohodnite ochranu pred prepnutím

Neprenášajte staré kryptografické nastavenia len preto, že sa objavujú v dodanom texte. Dohodnite prienik sád, ktoré obe nasadené protistrany aktuálne podporujú, a potvrďte ho s druhým administrátorom pred oknom zmeny. Ak sa ten prienik líši od toho, čo existujúca protistrana očakáva, je to koordinovaná zmena, nie lokálna úprava.

Zapíšte dohodnutú množinu. Dvaja administrátori s rozdielnymi spomienkami na telefonát sú dôvod, prečo prepnutie vytvorí nezhodu v druhej fáze.

Krok 5: overte službu, nie syntax

Najprv skontrolujte efektívne objekty cieľa, potom prijatú asociáciu, potom skutočný tok aplikácie a jeho odpoveď. Zadanie príkazu bez chyby dokazuje syntax a nič iné. Tunel, ktorý sa zdvihne a neprenáša prevádzku, zvyčajne znamená, že chránené rozsahy alebo spiatočná trasa nesúhlasia s druhou stranou, čo je problém riadkov požiadaviek, nie problém príkazov. Porovnajte chránené rozsahy na oboch stranách, kým sa znova dotknete crypto map.

Zaznamenajte, čo ste overili, s ktorými adresami, z ktorej strany. Ten záznam mení nejasné tvrdenie, že VPN je hore, na niečo, čo druhý administrátor môže nezávisle skontrolovať.

Čo vrátiť

Pošlite maticu požiadaviek, zhrnutie cieľovej konfigurácie a výsledky overenia. Výslovne uveďte, ktoré zdrojové nastavenia ste nepreniesli a prečo. Ten zoznam je užitočnejší než preložená konfigurácia, pretože tam sa začne ďalšia nezhoda.

Ponechajte aj zdrojový text pri tikete. Dokumentuje, čo sa žiadalo, kým matica dokumentuje, čo sa dohodlo.