Split-туннель не освобождает публичный хост от правил NAT на ASA

Маршрут split-include втягивает публичный хост в туннель, где ASA должна выполнить hairpin и транслировать источник. Пропустите любой из двух шагов — и поток оборвётся.

Split-туннелирование обычно описывают как способ держать корпоративный трафик внутри туннеля, а остальной интернет — за пределами межсетевого экрана. Обе половины этого описания неверны одинаково. Split-туннелирование — это решение о маршруте, которое принимает клиент, а решение о маршруте ничего не говорит о том, что произойдёт с пакетом после того, как он достигнет headend.

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

Миф: split-туннель убирает межсетевой экран с пути

Считается, что любое назначение вне частных диапазонов остаётся на локальном интернет-подключении, поэтому межсетевой экран его никогда не видит и никогда не нуждается в правиле для него. Это верно только до тех пор, пока назначения нет в списке туннеля. В тот момент, когда администратор добавляет публичный хост в ACL split-include, клиент отправляет этот трафик в туннель, и ASA должна маршрутизировать, фильтровать и транслировать его, как любой другой расшифрованный поток. На клиенте не изменилось ничего, кроме списка назначений.

Клиент не стал маршрутизатором. Он последовал политике, которую вы ему дали.

Что на самом деле делает маршрут split-include

В конфигурации удалённого доступа Cisco ASA групповая политика содержит split-tunnel-policy tunnelspecified и split-tunnel-network-list, который называет стандартный ACL. Каждая строка permit в этом ACL — это назначение, которое клиент должен отправить в туннель, а всё остальное продолжает использовать локальный маршрут по умолчанию.

Добавление одного хоста — это одна строка, и это единственная часть изменения, которую клиент может увидеть: access-list RA-SPLIT standard permit host 203.0.113.20.

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

Пакет приходит и уходит через тот же интерфейс

Теперь проследите поток после расшифровки. Пакет вошёл через внешний интерфейс по туннелю VPN, его назначение — публичный адрес, и таблица маршрутизации отправляет его обратно через тот же внешний интерфейс в сторону интернета. Трафик, который входит и выходит через один интерфейс, отбрасывается, если ASA не разрешено его пропускать, и именно это делает same-security-traffic permit intra-interface. Без этого соединение падает так, что выглядит как проблема маршрутизации, но ею не является.

Этот параметр глобальный. Он разрешает hairpinning для каждого потока, которому это нужно, а не только для этого партнёрского хоста, поэтому он относится к проверенному изменению, а не к быстрому тесту.

Почему PAT, ограниченный назначением, не является необязательным

Адрес источника в расшифрованном пакете по-прежнему остаётся VPN-адресом клиента, обычно из пула вроде 10.77.0.0/24. У этого адреса нет маршрута в публичном интернете, поэтому партнёр либо никогда не отвечает, либо отвечает в никуда.

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

same-security-traffic permit intra-interface

object network RA_POOL
 subnet 10.77.0.0 255.255.255.0
object network PARTNER_HOST
 host 203.0.113.20

nat (outside,outside) source dynamic RA_POOL interface destination static PARTNER_HOST PARTNER_HOST

Часть destination static важна. Если её убрать, правило превратится в широкую трансляцию, которая может совпасть с гораздо большим объёмом трафика, чем задумано, а широкое правило identity, расположенное раньше в порядке, может полностью его побить. Проверьте show nat detail и порядок разделов, прежде чем предполагать, что совпадает именно ваше правило.

PAT на интерфейсе также означает, что партнёр видит адрес интерфейса ASA, который может быть транслирован ещё раз выше по потоку. Если договор называет адрес, подтвердите его от начала до конца, а не на одном переходе.

Докажите это правильным тестовым назначением

Используйте сам партнёрский хост, а не типовую страницу what-is-my-ip. Та страница почти наверняка находится вне split-списка, поэтому сообщает ваш локальный интернет-адрес и ничего не говорит об этом пути. Откройте новое соединение со службой партнёра и спросите, какой источник они наблюдали, или выполните packet-tracer input outside tcp 10.77.0.10 12345 203.0.113.20 443 detailed и прочитайте этапы NAT и маршрутизации строка за строкой. Traceroute с клиента — более слабая проверка, потому что показывает путь, который уже произошёл, а не политику, которая его выбрала.

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

Работающая версия этого проекта коротка: один хост в ACL split, разрешение hairpin, одно правило PAT, ограниченное назначением. Всё остальное в этой истории — миф.

Похожие статьи