ASA VPN hairpin: маршрутизация двух туннелей через один интерфейс

Трафик удалённого пользователя может выходить через тот же интерфейс ASA, через который пришёл, но разрешение hairpin, область действия туннеля, NAT и ACL — это четыре отдельных решения.

Удалённый пользователь подключается к ASA, запрашивает хост за филиалом, и ASA отправляет этот запрос через тот самый интерфейс, через который пришёл пользователь. Ничего из этого не требует второго физического порта. Требуются четыре независимых решения, которые люди склонны сливать в одно: разрешение на hairpin, туннель, защищающий правильные адреса, политика NAT, сохраняющая обещанный источник, и политика доступа, разрешающая службу.

Один пакет, два туннеля

Проследите поток, и порядок операций перестаёт быть загадочным. Пакет приходит внутри туннеля удалённого доступа, расшифровывается и становится обычным IP-пакетом с источником из пула клиентов. Затем ASA маршрутизирует его, сопоставляет с crypto ACL «сайт — сайт», снова шифрует и отправляет через внешний интерфейс в сторону филиала.

Адреса ниже приведены для примера, но форма важна: источник — это пул, а не внутренняя LAN ASA.

remote client 10.77.0.20
  -> remote-access tunnel, terminated on ASA outside
  -> decrypted, routed, matched against site-to-site policy
  -> site-to-site tunnel, sent from ASA outside
  -> branch host 10.60.20.10

Отсюда следуют две вещи. Клиенту нужен маршрут к префиксу филиала через его подключение удалённого доступа, а значит, split-tunnel или передаваемый список маршрутов должен его включать. И филиал должен знать, как возвращать трафик на 10.77.0.20 или на адрес, который подставил ваш проект NAT.

Разрешение hairpin действует глобально

Команда, к которой обычно тянутся, — same-security-traffic permit intra-interface. Она разрешает трафику входить и выходить через один и тот же интерфейс, что как раз и нужно этому пути. Это ещё и глобальная настройка: её включение меняет поведение других потоков, которые случайно проходят через тот же интерфейс дважды.

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

Область защиты и NAT раздельны

Туннель «сайт — сайт» защищает то, что выбирает его crypto ACL. Если этот ACL указывает внутреннюю подсеть ASA как источник, пул удалённого доступа не защищён, и пакет будет либо отброшен, либо отправлен открыто, в зависимости от поведения платформы с несовпадающим трафиком. Добавьте пул в защищаемый поток, когда проект сохраняет адреса пула.

Затем NAT решает, сохранится ли адрес пула. Identity NAT сохраняет его, и филиал видит 10.77.0.20 как источник. Трансляция меняет договор: филиал теперь возвращает трафик на транслированный адрес, и его собственная политика должна это принимать. Порядок правил определяет, сопоставляется ли crypto ACL до или после трансляции, поэтому читайте фактический поток, а не предполагайте, кто победит.

Не удаляйте общие правила PAT для интернета, чтобы заработал один транзитный случай. Целенаправленное исключение или намеренное правило identity проще объяснить и отменить, чем дыру в исходящей политике.

Шифрование не является авторизацией

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

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

Hairpin или второй интерфейс

Транзит через hairpin делает проект компактным и стоит одной глобальной настройки. Отдельный интерфейс или туннель на основе маршрутизации с собственным виртуальным интерфейсом изолирует транзитный путь и даёт политику для каждого интерфейса, ценой адресации и ещё одной crypto map или профиля. Ни один не правильнее; они отказывают по-разному.

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

Проверяйте с реального клиента

Проверка, запущенная с ASA, имеет другой адрес источника и не пройдёт путь от пула до филиала. Используйте packet-tracer для проверки пятёрки, затем откройте настоящее соединение с фактического удалённого клиента, потому что трассировщик моделирует и не заменяет собственные маршрутизацию и политику клиента.

После планового изменения подключитесь к службе, которая должна работать, затем к той, которая должна быть отклонена, и подтвердите обратный маршрут филиала. примеры Cisco для hairpin NAT в VPN наглядно разделяют разрешение intra-interface, NAT и ACL, и это та мысленная модель, которую стоит копировать.

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