Туннельный маршрут по умолчанию на 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 выбрала путь, а последние два — что на нём кто-то отвечает.

Если шлюз отвечает, а клиент ответа не видит, посмотрите трансляцию источника и обратный маршрут, прежде чем снова трогать таблицу маршрутизации.

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