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 помилки.