Selitev VPN z IOS na ASA: prevedite dogovor, ne CLI

Konfiguracija IOS, ki pride kot referenca za selitev na ASA, opisuje dogovor, zavit v sintakso ene platforme. Naslovi nasprotne strani, identitete in zaščiteni obsegi so dogovor. Obroč ključev, profil in veriga crypto map so način, kako to izraža IOS, medtem ko ASA isti namen izraža prek tunnel group in njihovih atributov. Kopiranje drugega dela nikoli ne deluje, kopiranje samo prvega pa pusti delo na pol.

Pojdite skozi pet korakov spodaj po vrsti in se ustavite povsod, kjer dve platformi opisujeta različne stvari, ne različnih besed.

Korak 1: ločite dogovor od sintakse

Zapišite predajo kot zahteve, o katerih se strinjata oba skrbnika. Štiri vrstice pokrijejo skoraj vse: kje je nasprotna stran in katera stran začne, kako vsaka stran dokaže svojo identiteto, kakšna zaščita je sprejemljiva in katere aplikacije morajo preživeti tunel. Nobena od teh vrstic ne omenja ukaza.

Ohranite izvirno besedilo kot dokaz, ne kot navodilo. Vrstica, ki obstaja na eni platformi in ne na drugi, je razlika v sintaksi, dokler ne preverite, ali je mogoče isto zahtevo izpolniti drugače.

Korak 2: poimenujte objekte na vsaki platformi

Na IOS XE obroč ključev IKEv2 napaja profil IKEv2, ta profil pa se pripne prek crypto map ali profila IPsec. Na ASA tunnel group hrani profil povezave in njegove atribute IPsec, crypto map pa kaže nanj, kot opisuje vodnik po profilu povezave. To so različni grafi objektov z različnim dedovanjem, zato preslikava vrstico za vrstico da konfiguracijo, ki se razčleni in ne poveže.

Ciljne objekte zgradite iz vrstic zahtev, ne iz izvirnih vrstic. Če so vrstice popolne, je ciljna konfiguracija oblikovalska odločitev. Če niso, nobena količina prevajanja ukazov ne bo dostavila manjkajočega namena.

Korak 3: prenesite identiteto, ne le naslovov

Identiteta je del, ki se tiho zlomi. Nasprotna stran, ki se preverja z naslovom, se obnaša drugače od tiste, ki se preverja s subjektom potrdila ali FQDN, in obe platformi to pričakovanje zabeležita na različnih mestih. Ohranite predvideno identiteto in verigo zaupanja, namesto da bi zamenjali skupno skrivnost zato, ker jo je lažje preizkusiti.

Skupno skrivnost hranite zunaj primerjalnih opomb in zahtevkov. Zabeležite, kdo jo ima in kako potuje po odobrenem kanalu, in ne pozabite, da nadomestni znak iz primera v dokumentaciji ni poverilnica stranke.

Korak 4: dogovorite zaščito pred preklopom

Starih kriptografskih nastavitev ne prenašajte samo zato, ker so v priloženem besedilu. Dogovorite se o preseku nizov, ki jih obe nameščeni nasprotni strani trenutno podpirata, in ga potrdite z drugim skrbnikom pred oknom spremembe. Če se ta presek razlikuje od tistega, kar pričakuje obstoječa nasprotna stran, gre za usklajeno spremembo, ne lokalni popravek.

Zapišite dogovorjeni niz. Dva skrbnika z različnimi spomini na telefonski pogovor sta razlog, da preklop povzroči neskladje v drugi fazi.

Korak 5: preverite storitev, ne sintakse

Najprej preverite učinkovite objekte cilja, nato sprejeto asociacijo, nato resničen tok aplikacije in njegov odgovor. Vnos ukaza brez napake dokaže sintakso in nič drugega. Tunel, ki se dvigne in ne prenaša prometa, običajno pomeni, da se zaščiteni obsegi ali povratna pot ne ujemajo z drugo stranjo, kar je težava vrstic zahtev, ne ukazov. Primerjajte zaščitene obsege na obeh straneh, preden se znova dotaknete crypto map.

Zabeležite, kaj ste preverili, s katerimi naslovi, s katere strani. Ta zapis spremeni nejasno trditev, da VPN deluje, v nekaj, kar lahko drugi skrbnik neodvisno preveri.

Kaj vrniti

Pošljite matriko zahtev, povzetek ciljne konfiguracije in rezultate preverjanja. Izrecno navedite, katerih izvirnih nastavitev niste prenesli in zakaj. Ta seznam je bolj uporaben od prevedene konfiguracije, ker se tam začne naslednje nesoglasje.

Tudi izvirno besedilo hranite pri zahtevku. Dokumentira, kaj je bilo zahtevano, medtem ko matrika dokumentira, kaj je bilo dogovorjeno.