Две криптокарты, один поток: поздняя запись — не резерв

Добавьте вторую запись криптокарты для той же пары адресов, направьте её на другого партнёра — и вы написали план переключения при отказе. Это миф, и он живёт потому, что выглядит как любой другой упорядоченный список, который вы настраивали. Порядок в криптокарте решает, какая запись захватит новый поток, а не какая запись перехватит управление, когда партнёр перестанет отвечать. Ничто в этом списке не следит за дальним концом, поэтому вторая запись просто сидит там и ничего не захватывает.

Миф: порядок означает резерв

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

То, что вы построили, — это политика, к которой для этого потока никогда не обратятся, плюс комментарий в записи изменений, утверждающий избыточность.

Порядок захватывает поток, и только один раз

Каждая запись содержит список контроля доступа или определение защищённого потока, и каждый новый исходящий пакет сравнивается с этими определениями по порядку. Первая запись, чьё определение совпадает, владеет потоком и своим партнёром. Вторая запись с идентичным определением никогда не получает очереди, потому что первая уже совпала; вторая запись с более узким определением обслуживает только потоки, которые первая не захватила.

Такое поведение полезно, когда вы намеренно вырезаете исключения из широкой политики, и оно бесполезно как механизм переключения при отказе. Проверьте, что произошло на самом деле, с помощью show crypto map и show crypto ipsec sa peer, затем проследите синтетический пакет по пути, который, по вашему мнению, он проходит. Трассировка назовёт запись, которая его захватила, и это единственный ответ, который имеет значение.

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

Таблица маршрутизации отвечает, куда пересылается пакет. Криптополитика отвечает, какая защита и какой партнёр применяются к выбранному трафику. Дублирование пары источника и назначения под другим партнёром меняет второе решение и оставляет первое нетронутым, поэтому ответы могут по-прежнему идти через старый шлюз, пока исходящий пакет идёт к новому партнёру. Эта асимметрия создаёт туннель, который отчитывается о работе и ничего не пропускает.

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

Что нужно настоящему альтернативному пути

Выберите механизм, созданный для задачи: поддерживаемая группа кандидатов-партнёров, маршрутизируемый туннель с плавающей статикой или динамическим маршрутным соседством поверх него, либо любой проект резервирования, который ваша платформа документирует для этого сервиса. Затем запишите, какой компонент обнаруживает отказ и какой компонент выбирает альтернативу, потому что это две разные функции и часто две разные команды.

Трансляция адресов тоже может дать площадке второй представленный адрес, но она одновременно меняет селекторы, журналирование и правила доступа на основе источника. Относитесь к этому как к явному требованию, а не как к обходному пути для двух неоднозначных записей.

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

Конфигурация завершена только тогда, когда у неё есть защищаемый ответ для нормальной работы, для состояния отказа основного и для возврата к основному. Проверьте все три и запишите, какая запись политики и какой партнёр обслуживали каждое. Тест, который останавливается после первого состояния, доказывает, что проект работает, когда всё в порядке, а это именно то состояние, которое вам не нужно было проверять.

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