Failback на ASA: что действительно перемещается, когда маршрут возвращается
Возврат маршрута на основной путь не означает, что старые потоки переехали. Наблюдайте вместе uplink, туннель, таблицу соединений и результат приложения.
На ASA с двумя uplink-ами failback не является обратным действием к failover. Маршрут к peer меняется, и затем платформа должна согласовать три отдельные машины состояний: таблицу маршрутизации, ассоциации безопасности IKE и IPsec и таблицу соединений. Каждая может отставать от других, и именно это отставание большинство людей называет туннелем, который не возвращается.
Что на самом деле меняет failback
Поиск по таблице маршрутов — видимая часть. Когда отслеживаемый объект восстанавливается, отслеживаемый маршрут к внешнему адресу peer возвращается, и следующий пакет, который отправляет ASA, снова идёт по основному каналу. Всё дальнейшее зависит от того, согласуется ли текущее состояние с новым путём.
ARP и NAT — тихие зависимости. Новому next hop нужен разрешимый шлюз и трансляция, которая всё ещё соответствует удалённой стороне, иначе первые пакеты после failback никуда не уходят, а маршрут выглядит правильно, пока ничего не работает.
Четыре вида на одной временной шкале
Записывайте одни и те же четыре вещи до перехода, во время него и после, потому что один снимок не может сказать, какой уровень сдвинулся.
| View | What to record |
|---|---|
| Uplink and route | Interface state, the tracked object result, the route selected for the outer peer address |
| IKE and IPsec | The live peer, IKE version, security associations, protected-traffic counters |
| Connection table | Interface and endpoint pair for old flows and for flows created after the change |
| Application | One pre-existing operation and one fresh request, each marked success, reset, stall or recovered |
Маршрут, который никогда не менялся, и маршрут, который изменился, пока более старое соединение сохраняло своё состояние пересылки, дают одинаковую жалобу и совершенно разные доказательства.
Почему старые соединения остаются на резервном пути
ASA не разрывает поток из-за того, что изменился маршрут. Установленные соединения сохраняют решение о пересылке, с которым были созданы, а платформа предоставляет отдельные средства управления тем, как долго это разрешено: floating-connection timeout и connection holddown. руководство Cisco по настройкам соединений в ASA 9.24 от Cisco рассматривает их как разные вопросы, и именно так они себя и ведут. Одно управляет выживанием существующего потока, другое — когда новые потоки могут использовать предпочтительный путь.
Прочитайте действующие значения для своей версии, прежде чем менять любое из них. Их снижение закрывает сеансы, которые люди ещё используют. Их повышение создаёт впечатление, что failback не произошёл, потому что новые соединения всё это время идут по старому пути.
Туннель не пересогласовывает ключи из-за возврата маршрута
Ассоциации безопасности IPsec несут собственное согласованное время жизни и переживают изменение маршрута, который их нёс. Поэтому туннель может оставаться поднятым через failback, тогда как его внешняя адресация уже не соответствует используемому пути; это аргумент в пользу DPD и схем, которые фиксируют адрес peer вместо того, чтобы позволять ему плавать.
Схемы crypto-map и VTI ведут себя здесь иначе, а документация Cisco по 9.24 VTI описывает вариант на основе маршрутов. Старое общее утверждение, что ASA не может запускать VPN на основе маршрутов, неверно для поддерживаемых версий.
Читайте доказательства в этом порядке
Начните с плоскости управления: show route для выбранного пути, show interface для состояния канала и счётчики SLA-монитора для отслеживаемого объекта. Затем прочитайте show crypto ikev2 sa, или эквивалент IKEv1, чтобы увидеть, какой peer активен, после чего show crypto ipsec sa для защищённых потоков. Затем сузьте таблицу соединений с помощью show conn address <host> и сравните столбец интерфейса в старых и новых записях. Записывайте выводы с отметками времени, потому что их порядок и есть диагноз.
Завершите тестом приложения: один поток, который уже существовал, и один, созданный после возврата маршрута. Если старый поток отказывает, а новый работает, у вас есть история состояния соединения. Если отказывают оба, туннель или политика неверны, а таблица соединений — отвлечение.
Держите эту запись в одной и той же форме на всех трёх этапах и отметьте точную версию. Когда временная шкала продолжает указывать на один переход, отправьте запись в поддержку, а не угадывайте ID ошибки.