Тунельний маршрут за замовчуванням на Cisco ASA: коли він справді застосовується

Користувач віддаленого доступу не дістає нічого за ASA, хоча той самий сервер відповідає на ping з внутрішньої LAN. Тунель піднімається, клієнт отримує адресу з пулу, а пакет усе одно виходить через інтернет-маршрут за замовчуванням або зникає. Така картина зазвичай означає, що розшифрований трафік не знайшов власного маршруту й провалився на звичайний маршрут за замовчуванням. Виправлення — не ще одне правило NAT; виправлення — це тунельний маршрут за замовчуванням.

Почніть із симптому, а не з конфігурації

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

У show vpn-sessiondb тунель виглядає здоровим, і саме тому люди продовжують налагоджувати IKE.

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

Чим тунельний пошук відрізняється

Посібник Cisco з статичної маршрутизації на ASA 9.23 описує окремий маршрут за замовчуванням для розшифрованого VPN-трафіку, який не має статичного чи вивченого маршруту. Ключове слово tunneled позначає цей маршрут, тож розшифрований пакет може перейти на наступний вузол, відмінний від того, який ASA використовує для власного транспорту. Конкретніші маршрути все одно перемагають, тому клієнт може дістатися до 10.0.0.0/8 через внутрішній шлюз і втратити все інше.

Мінімальна схема тримає два маршрути за замовчуванням із різними наступними вузлами. Один несе власний трафік ASA, інший — розшифрований трафік, який не має кращого маршруту. Обидва наступні вузли все ще мають бути доступними з інтерфейсу, до якого ви їх прив'язуєте.

route outside 0.0.0.0 0.0.0.0 198.51.100.1
route outside 0.0.0.0 0.0.0.0 10.20.30.1 tunneled

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

Обмеження, від яких залежить, чи працюватиме це

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

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

Відстеження маршрутів — окрема пастка: відстежуваний об'єкт зазвичай охороняє звичайний маршрут за замовчуванням, а не тунельний.

Чого ключове слово не робить

Воно не вибирає адресу джерела, яку ASA використовує для побудови IKE. Зовнішня точка тунелю підкоряється власному вибору інтерфейсу й джерела платформи, і тунельний маршрут за замовчуванням не бере участі в цьому рішенні. Його зміна не виправить phase 1, який виходить із неправильної адреси.

Воно також не перетворює наступний вузол на проксі. Якщо призначення очікує обмін HTTP CONNECT, надсилання сирих IP-пакетів на проксі-хост дає лише хост, який їх не маршрутизує. Натомість налаштуйте механізм проксі, який підтримує клієнт.

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

Перевірте шлях від початку до кінця

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

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

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