ASA hairpin: выход в интернет или плечо VPN между площадками?

Пул клиентов может уходить в интернет или в VPN площадки. Решите, какое плечо нужно, до написания NAT, затем проверьте маршрут, селектор и обратный путь.

Два пользователя удалённого доступа за одним и тем же ASA могут отправлять трафик через один и тот же внешний интерфейс и получать совершенно разное обращение. Один идёт на публичный сайт, поэтому пакету нужна трансляция источника и интернет-маршрут. Другой идёт на сервер за туннелем между площадками, который тоже завершается на этом интерфейсе, поэтому пакету нужны идентичность, подходящий селектор туннеля и обратный путь к пулу клиентов. Разрешение для одного и того же интерфейса — предпосылка для обоих и решение ни для одного.

Два плеча, один интерфейс

Решите, какое плечо вы строите, прежде чем вводить правило NAT, потому что правила не взаимозаменяемы. Плечо A — от клиента в интернет: адрес пула внутрь, транслированный публичный адрес наружу, обратно через тот же интерфейс. Плечо B — от клиента к частному префиксу на дальней стороне другого партнёра IPsec: адрес пула сохраняется, повторно шифруется и доставляется партнёру, который должен знать, как ответить пулу.

Обоим сначала нужно разрешение для одного и того же интерфейса. Без него ASA отказывается пересылать пакет через интерфейс, на который он пришёл, и отказ выглядит как проблема маршрутизации, а не политики:

same-security-traffic permit intra-interface

Эта одна строка разрешает схему пересылки, как описывает справочник по NAT в ASA для путей через один интерфейс. Она не добавляет маршрут клиента, не авторизует ресурс, не транслирует адрес и не согласует селектор IPsec, поэтому ожидайте, что после неё понадобится добавить ещё три-четыре вещи, и не читайте её принятие как прогресс.

Плечо A: клиент хочет в интернет

Для выхода в интернет адрес пула должен перестать быть частным до того, как пакет покинет устройство. В обычной схеме PAT правило транслирует пул в адрес внешнего интерфейса, а состояние возврата восстанавливает поток к клиенту:

object network VPN_POOL
 subnet 10.80.0.0 255.255.255.0
nat (outside,outside) after-auto source dynamic VPN_POOL interface route-lookup

Затем убедитесь, что клиент действительно попросил ASA нести этот трафик. Исключение из раздельного туннеля отправляет публичное назначение через собственное соединение телефона, которое никогда не доходит до ASA, и ни одно правило NAT не исправит пакет, который никогда не был отправлен. Сравните список раздельного туннеля групповой политики с назначением, которое вы тестируете.

Остальная часть плеча обычная: пригодный маршрут по умолчанию или конкретный маршрут из внешнего интерфейса, политика доступа, разрешающая поток, и DNS, обрабатываемый согласно выбранной политике резолвера. Добавьте route-lookup здесь по той же причине, что и ниже, поскольку входной и выходной интерфейсы совпадают.

Плечо B: клиент хочет частную площадку

Это плечо отказывает в большем числе мест, поэтому пишите его по порядку. Сначала маршрут клиента: префикс назначения должен быть в списке раздельного туннеля, иначе клиент не поместит его в туннель. Затем селектор туннеля: крипто-ACL между площадками должен покрывать адрес пула до удалённого префикса, а не только локальную LAN до удалённого префикса. И наконец идентичность, чтобы адрес пула по пути не транслировался в интернет-PAT.

nat (outside,outside) source static VPN_POOL VPN_POOL
    destination static SITE_PREFIX SITE_PREFIX route-lookup

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

Проверьте и порядок правил. Широкое правило PAT выше правила идентичности транслирует частный обмен ещё до того, как правило идентичности будет оценено, и симптом — туннель площадки без подходящего SA, а не ошибка NAT.

Тест, который говорит, какое плечо вы построили

Используйте собственную оценку пути на ASA, а не чтение конфигурации и надежду. packet-tracer input outside tcp 10.80.0.25 40000 203.0.113.10 443 detailed показывает решение NAT, маршрут и результат ACL для одного потока; повторите с частным назначением. Если фаза NAT переписывает поток из частного в частное, вы построили плечо A для пакета, которому было нужно плечо B.

Ещё две команды закрывают пробел. show nat detail печатает порядок правил, которого придерживался packet-tracer, и show crypto ipsec sa показывает, существует ли селектор для ожидаемой пары. Отсутствующий SA — вопрос настройки селектора или партнёра, а не то, что правило NAT может исправить.

Проверьте каждое плечо тем трафиком, которому оно служит

Примите плечо A обычным публичным запросом от клиента, а плечо B — запросом к частному ресурсу, который действительно существует. Затем повторите каждое с отклонённым ресурсом, потому что «разрешено» и «одобрено политикой доступа» — не одно и то же доказательство, и ping, исходящий из концентратора, не упражняет ни один из клиентских путей.

Держите две записи теста раздельно в тикете: адрес источника, назначение, совпавшее правило NAT и результат. Когда следующий отчёт скажет «VPN сломан», эта пара в течение минуты скажет, какое плечо деградировало, и ответ обычно — маршрут или селектор, а не строка того же интерфейса, которую все подозревают первой.

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