Дві криптокарти, один потік: пізніший запис — не резерв

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

Міф: порядок означає резерв

Упорядкований список із двома записами й одним спільним визначенням сприймається як основний і резервний. Схожість закінчується на синтаксисі. Документація Cisco для ASA описує криптокарту як модель політики, що зіставляє захищений трафік і задає для нього схему партнерів, а зіставлення відбувається із записом, який захоплює потік першим. Доступність віддаленого партнера не входить до цієї оцінки.

Те, що ви побудували, — це політика, до якої для цього потоку ніколи не звернуться, плюс коментар у записі змін, що стверджує надмірність.

Порядок захоплює потік, і лише один раз

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

Така поведінка корисна, коли ви навмисно вирізаєте винятки з широкої політики, і вона марна як механізм перемикання при відмові. Перевірте, що сталося насправді, за допомогою show crypto map і show crypto ipsec sa peer, потім простежте синтетичний пакет шляхом, яким, на вашу думку, він іде. Трасування назве запис, який його захопив, і це єдина відповідь, що має значення.

Вибір маршруту й володіння політикою — різні рішення

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

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

Що потрібно справжньому альтернативному шляху

Виберіть механізм, створений для завдання: підтримувана група кандидатів-партнерів, маршрутизований тунель із плаваючою статикою або динамічним маршрутним сусідством поверх нього, або будь-який проєкт резервування, який ваша платформа документує для цього сервісу. Потім запишіть, який компонент виявляє відмову і який компонент вибирає альтернативу, бо це дві різні функції й часто дві різні команди.

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

Перевіряйте три стани, а не один

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

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