Миграција VPN-а са IOS на ASA: преведите договор, а не CLI

IOS конфигурација која стиже као референца за миграцију на ASA описује договор умотан у синтаксу једне платформе. Адресе друге стране, идентитети и заштићени опсези јесу договор. Прстен кључева, профил и ланац крипто мапе јесу начин на који то изражава IOS, док ASA исти циљ изражава кроз tunnel-group-ове и њихове атрибуте. Копирање другог дела никада не ради, а копирање само првог оставља посао пола обављеним.

Прођите кроз пет корака испод по реду и зауставите се свуда где две платформе описују различите ствари, а не различите речи.

Корак 1: одвојте договор од синтаксе

Напишите предају као захтеве око којих се слажу оба администратора. Четири реда покривају скоро све: где је друга страна и која страна иницира, како свака страна доказује идентитет, која је заштита прихватљива и које апликације морају да преживе тунел. Ниједан од тих редова не помиње команду.

Држите оригинални текст као доказ, а не као упутство. Ред који постоји на једној платформи а не на другој јесте разлика у синтакси, све док не проверите да ли се исти захтев може испунити на други начин.

Корак 2: именујте објекте на свакој платформи

На IOS XE прстен IKEv2 кључева напаја IKEv2 профил, а тај профил се повезује кроз крипто мапу или IPsec профил. На ASA tunnel-group држи профил везе и његове IPsec атрибуте, а крипто мапа показује на њега, како описује водич за профил везе. То су различити графови објеката са различитим наслеђивањем, због чега мапирање ред по ред даје конфигурацију која се парсира и не повезује се.

Градите циљне објекте из редова захтева, а не из изворних редова. Ако су редови потпуни, циљна конфигурација је пројектна одлука. Ако нису, никаква количина превођења команди неће обезбедити намеру која недостаје.

Корак 3: пренесите идентитет, не само адресе

Идентитет је део који се тихо квари. Страна која се аутентификује адресом понаша се другачије од оне која се аутентификује субјектом сертификата или FQDN-ом, а две платформе ту очекивану вредност бележе на различитим местима. Сачувајте намеравани идентитет и ланац поверења уместо да замените заједничку тајну зато што је лакше тестирати.

Држите заједничку тајну ван бележака за поређење и тикета. Забележите ко је власник и како се преноси одобреним каналом, и запамтите да чувар места из примера у документацији није креденцијал клијента.

Корак 4: договорите заштиту пре преласка

Немојте преносити старе криптографске поставке само зато што се појављују у достављеном тексту. Договорите пресек скупова које оба распоређена партнера тренутно подржавају и потврдите га са другим администратором пре прозора промене. Ако се тај пресек разликује од онога што постојећа страна очекује, то је координисана промена, а не локална измена.

Запишите договорени скуп. Два администратора са различитим сећањем на телефонски разговор јесу начин на који прелазак производи неслагање у другој фази.

Корак 5: проверите услугу, не синтаксу

Прво проверите ефективне објекте циља, затим прихваћену асоцијацију, затим стварни ток апликације и његов одговор. Унос команде без грешке доказује синтаксу и ништа друго. Тунел који се подигне и не преноси саобраћај обично значи да се заштићени опсези или повратна рута не слажу са другом страном, што је проблем редова захтева, а не команди. Упоредите заштићене опсеге на обе стране пре него што поново дирате крипто мапу.

Забележите шта сте проверили, са којим адресама, са које стране. Тај запис претвара нејасну тврдњу да је VPN горе у нешто што други администратор може независно да провери.

Шта вратити

Пошаљите матрицу захтева, резиме циљне конфигурације и резултате верификације. Изричито наведите које изворне поставке нисте пренели и зашто. Та листа је кориснија од преведене конфигурације, јер ће ту почети следеће неслагање.

Држите и изворни текст уз тикет. Он документује шта је тражено, док матрица документује шта је договорено.