Міграція VPN з IOS на ASA: перекладайте угоду, а не CLI

Конфігурація IOS, що надходить як еталон для міграції на ASA, описує угоду, загорнуту в синтаксис однієї платформи. Адреси пірів, ідентичності та захищені діапазони — це і є угода. Key ring, профіль і ланцюг crypto map — те, як IOS її виражає, тоді як ASA виражає той самий намір через tunnel group та їхні атрибути. Копіювання другої частини ніколи не працює, а копіювання лише першої залишає роботу наполовину зробленою.

Пройдіть наведені нижче п'ять кроків по порядку і зупиніться там, де дві платформи описують різні речі, а не різні слова.

Крок 1: відокремте угоду від синтаксису

Запишіть передачу як вимоги, з якими погоджуються обидва адміністратори. Чотири рядки покривають майже все: де пір і яка сторона ініціює, як кожна сторона доводить свою ідентичність, який захист прийнятний і які застосунки мають пережити тунель. Жоден із цих рядків не згадує команду.

Зберігайте оригінальний текст як доказ, а не як інструкцію. Рядок, що існує на одній платформі й відсутній на іншій, є різницею синтаксису, доки ви не перевірите, чи ту саму вимогу можна задовольнити іншим способом.

Крок 2: назвіть об'єкти на кожній платформі

На IOS XE key ring IKEv2 живить профіль IKEv2, і цей профіль приєднується через crypto map або профіль IPsec. На ASA tunnel group містить connection profile та його атрибути IPsec, а crypto map вказує на нього, як описує посібник із connection profile . Це різні графи об'єктів із різним успадкуванням, тому порівняння рядок за рядком дає конфігурацію, яка парситься й не з'єднується.

Будуйте цільові об'єкти з рядків вимог, а не з вихідних рядків. Якщо рядки повні, цільова конфігурація є проєктним рішенням. Якщо ні, жодна кількість перекладу команд не дасть відсутнього наміру.

Крок 3: переносьте ідентичність, а не лише адреси

Ідентичність — це частина, що ламається тихо. Пір, який автентифікується за адресою, поводиться інакше, ніж той, що автентифікується за суб'єктом сертифіката чи FQDN, і обидві платформи фіксують цю очікуваність у різних місцях. Збережіть задуману ідентичність і ланцюг довіри замість того, щоб підставити спільний секрет, бо його легше перевірити.

Тримайте спільний секрет поза нотатками порівняння та заявками. Запишіть, кому він належить і як проходить затвердженим каналом, і пам'ятайте, що заповнювач із прикладу в документації не є обліковими даними клієнта.

Крок 4: погодьте захист до перемикання

Не переносьте старі криптографічні налаштування лише тому, що вони є в наданому тексті. Погодьте перетин наборів, які обидва розгорнуті піри підтримують зараз, і підтвердьте його з іншим адміністратором до вікна змін. Якщо цей перетин відрізняється від очікувань наявного піра, це скоординована зміна, а не локальне редагування.

Запишіть узгоджений набір. Двоє адміністраторів із різними спогадами про телефонну розмову — саме так перемикання дає невідповідність другої фази.

Крок 5: перевіряйте сервіс, а не синтаксис

Спершу перевірте ефективні об'єкти цілі, потім прийняту асоціацію, потім реальний потік застосунку та відповідь. Введення команди без помилки доводить синтаксис і більше нічого. Тунель, що піднімається й не несе трафіку, зазвичай означає, що захищені діапазони або зворотний маршрут не збігаються з іншою стороною, а це проблема рядка вимог, не команди. Порівняйте захищені діапазони з обох боків, перш ніж знову торкатися crypto map.

Запишіть, що саме ви перевірили, з якими адресами, з якого боку. Цей запис перетворює неоднозначне твердження, що VPN працює, на те, що інший адміністратор може перевірити незалежно.

Що повернути

Надішліть матрицю вимог, стислий опис цільової конфігурації та результати перевірки. Явно вкажіть, які вихідні налаштування не перенесено і чому. Цей список корисніший за перекладену конфігурацію, бо саме там почнеться наступна незгода.

Зберігайте й вихідний текст у заявці. Він документує, що просили, а матриця — на що погодилися.