Migracija VPN-a s IOS-a na ASA: prevedite sporazum, a ne komande

IOS konfiguracija koja stiže kao referenca za migraciju na ASA opisuje sporazum umotan u sintaksu jedne platforme. Adrese partnera, identiteti i zaštićeni rasponi jesu sporazum. Prsten ključeva, profil i lanac kripto karata način su na koji to IOS izražava, dok ASA istu namjeru izražava kroz tunel grupe i njihove atribute. Kopiranje drugog dijela nikada ne radi, a kopiranje samo prvog ostavlja posao na pola.

Prođite kroz pet koraka ispod po redu i zaustavite se gdje god dvije platforme opisuju različite stvari, a ne različite riječi.

Korak 1: odvojite sporazum od sintakse

Napišite primopredaju kao zahtjeve oko kojih se oba administratora slažu. Četiri reda pokrivaju gotovo sve: gdje je partner i koja strana inicira, kako svaka strana dokazuje svoj identitet, koja je zaštita prihvatljiva i koje aplikacije moraju preživjeti kroz tunel. Nijedan od tih redova ne spominje komandu.

Čuvajte originalni tekst kao dokaz, a ne kao uputstva. Red koji postoji na jednoj platformi, a ne na drugoj, razlika je u sintaksi dok ne provjerite može li se isti zahtjev ispuniti na drugi način.

Korak 2: imenujte objekte na svakoj platformi

Na IOS XE prsten ključeva IKEv2 napaja IKEv2 profil, a taj se profil priključuje kroz kripto kartu ili IPsec profil. Na ASA tunel grupa drži profil veze i njegove IPsec atribute, a kripto karta pokazuje na nju, kako opisuje vodič kroz profil veze. To su različiti grafovi objekata s različitim nasljeđivanjem, zbog čega mapiranje red po red daje konfiguraciju koja se parsira, ali ne povezuje.

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

Korak 3: prenesite identitet, ne samo adrese

Identitet je dio koji se tiho lomi. Partner koji se autentificira adresom ponaša se drugačije od onog koji se autentificira subjektom certifikata ili FQDN-om, a dvije platforme tu očekivanje bilježe na različitim mjestima. Sačuvajte predviđeni identitet i lanac povjerenja umjesto da zamijenite zajedničku tajnu zato što je lakše testirati.

Držite unaprijed dijeljenu tajnu izvan bilješki za poređenje i tiketa. Zabilježite kome pripada i kako se kreće odobrenim kanalom, i zapamtite da rezervirano mjesto iz primjera u dokumentaciji nije klijentov akreditiv.

Korak 4: dogovorite zaštitu prije prelaska

Ne prenosite stare kriptografske postavke zato što se pojavljuju u dostavljenom tekstu. Dogovorite presjek skupova koje oba instalirana partnera trenutno podržavaju i potvrdite to s drugim administratorom prije prozora promjene. Ako se taj presjek razlikuje od onoga što postojeći partner očekuje, to je koordinirana promjena, a ne lokalna izmjena.

Zapišite dogovoreni skup. Dva administratora s različitim sjećanjima na telefonski razgovor način su na koji prelazak proizvodi nesklad u drugoj fazi.

Korak 5: provjerite uslugu, a ne sintaksu

Prvo provjerite efektivne objekte cilja, zatim prihvaćenu asocijaciju, a zatim stvarni tok aplikacije i njegov odgovor. Unošenje komande bez greške dokazuje sintaksu i ništa drugo. Tunel koji se podigne i ne nosi promet obično znači da se zaštićeni rasponi ili povratna ruta ne slažu s drugom stranom, a to je problem reda zahtjeva, a ne komande. Uporedite zaštićene raspone na obje strane prije nego što ponovo dotaknete kripto kartu.

Zabilježite šta ste provjerili, s kojim adresama i s koje strane. Taj zapis pretvara nejasnu tvrdnju da VPN radi u nešto što drugi administrator može samostalno provjeriti.

Šta vratiti

Pošaljite matricu zahtjeva, sažetak ciljne konfiguracije i rezultate provjere. Izričito navedite koje izvorne postavke niste prenijeli i zašto. Taj spisak je korisniji od prevedene konfiguracije, jer će se sljedeće neslaganje tu početi.

Sačuvajte i izvorni tekst uz tiket. On dokumentira što je traženo, a matrica što je dogovoreno.