Migracija VPN-a sa IOS na ASA: prevedite dogovor, a ne CLI

IOS konfiguracija koja stiže kao referenca za migraciju na ASA opisuje dogovor umotan u sintaksu jedne platforme. Adrese druge strane, identiteti i zaštićeni opsezi jesu dogovor. Prsten ključeva, profil i lanac kripto mape jesu način na koji to izražava IOS, dok ASA isti cilj izražava kroz tunnel-group-ove i njihove atribute. Kopiranje drugog dela nikada ne radi, a kopiranje samo prvog ostavlja posao pola obavljenim.

Prođite kroz pet koraka ispod po redu i zaustavite se svuda gde dve platforme opisuju različite stvari, a ne različite reči.

Korak 1: odvojte dogovor od sintakse

Napišite predaju kao zahteve oko kojih se slažu oba administratora. Četiri reda pokrivaju skoro sve: gde je druga strana i koja strana inicira, kako svaka strana dokazuje identitet, koja je zaštita prihvatljiva i koje aplikacije moraju da prežive tunel. Nijedan od tih redova ne pominje komandu.

Držite originalni tekst kao dokaz, a ne kao uputstvo. Red koji postoji na jednoj platformi a ne na drugoj jeste razlika u sintaksi, sve dok ne proverite da li se isti zahtev može ispuniti na drugi način.

Korak 2: imenujte objekte na svakoj platformi

Na IOS XE prsten IKEv2 ključeva napaja IKEv2 profil, a taj profil se povezuje kroz kripto mapu ili IPsec profil. Na ASA tunnel-group drži profil veze i njegove IPsec atribute, a kripto mapa pokazuje na njega, kako opisuje vodič za profil veze. To su različiti grafovi objekata sa različitim nasleđivanjem, zbog čega mapiranje red po red daje konfiguraciju koja se parsira i ne povezuje se.

Gradite ciljne objekte iz redova zahteva, a ne iz izvornih redova. Ako su redovi potpuni, ciljna konfiguracija je projektna odluka. Ako nisu, nikakva količina prevođenja komandi neće obezbediti nameru koja nedostaje.

Korak 3: prenesite identitet, ne samo adrese

Identitet je deo koji se tiho kvari. Strana koja se autentifikuje adresom ponaša se drugačije od one koja se autentifikuje subjektom sertifikata ili FQDN-om, a dve platforme tu očekivanu vrednost beleže na različitim mestima. Sačuvajte nameravani identitet i lanac poverenja umesto da zamenite zajedničku tajnu zato što je lakše testirati.

Držite zajedničku tajnu van beležaka za poređenje i tiketa. Zabeležite ko je vlasnik i kako se prenosi odobrenim kanalom, i zapamtite da čuvar mesta iz primera u dokumentaciji nije kredencijal klijenta.

Korak 4: dogovorite zaštitu pre prelaska

Nemojte prenositi stare kriptografske postavke samo zato što se pojavljuju u dostavljenom tekstu. Dogovorite presek skupova koje oba raspoređena partnera trenutno podržavaju i potvrdite ga sa drugim administratorom pre prozora promene. Ako se taj presek razlikuje od onoga što postojeća strana očekuje, to je koordinisana promena, a ne lokalna izmena.

Zapišite dogovoreni skup. Dva administratora sa različitim sećanjem na telefonski razgovor jesu način na koji prelazak proizvodi neslaganje u drugoj fazi.

Korak 5: proverite uslugu, ne sintaksu

Prvo proverite efektivne objekte cilja, zatim prihvaćenu asocijaciju, zatim stvarni tok aplikacije i njegov odgovor. Unos komande bez greške dokazuje sintaksu i ništa drugo. Tunel koji se podigne i ne prenosi saobraćaj obično znači da se zaštićeni opsezi ili povratna ruta ne slažu sa drugom stranom, što je problem redova zahteva, a ne komandi. Uporedite zaštićene opsege na obe strane pre nego što ponovo dirate kripto mapu.

Zabeležite šta ste proverili, sa kojim adresama, sa koje strane. Taj zapis pretvara nejasnu tvrdnju da je VPN gore u nešto što drugi administrator može nezavisno da proveri.

Šta vratiti

Pošaljite matricu zahteva, rezime ciljne konfiguracije i rezultate verifikacije. Izričito navedite koje izvorne postavke niste preneli i zašto. Ta lista je korisnija od prevedene konfiguracije, jer će tu početi sledeće neslaganje.

Držite i izvorni tekst uz tiket. On dokumentuje šta je traženo, dok matrica dokumentuje šta je dogovoreno.