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

Проверка 1: туннель защищает адрес источника

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

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

Остановитесь здесь, если защищённый диапазон и адрес источника не совпадают.

Проверка 2: решите, какой источник увидит филиал

Филиал видит либо исходный адрес клиента, либо транслированный, и этот выбор определяет обратный путь. Сохранение адреса клиента читается чище в журналах источника, но тогда филиал должен отправлять ответы для публичных клиентов обратно через туннель; обычный интернет-маршрут по умолчанию отправляет их в другую сторону, и соединение умирает в одном направлении. Трансляция источника в адрес, который филиал уже маршрутизирует через туннель, убирает это требование.

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

Проверка 3: пишите трансляцию под реальные интерфейсы

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

Путь, который вы строите, состоит из четырёх участков, и все четыре должны совпасть:

LegSourceDestination
Request from the internet198.51.100.25203.0.113.20:443
After destination translation198.51.100.2510.60.20.10:443
After source translation toward the tunnel10.10.250.1010.60.20.10:443
Branch reply10.60.20.1010.10.250.10
Restored reply to the client203.0.113.20198.51.100.25

Считайте диапазоны в этой таблице заполнителями. Важно то, что кортеж после трансляции — это адрес, который филиал принимает через туннель, и что обратное сопоставление существует в состоянии NAT, чтобы ответ восстанавливался на выходе.

Проверка 4: ограничьте правило доступа опубликованным портом

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

Проверьте порядок правил одновременно. Широкое разрешение над вашим конкретным правилом делает конкретное правило невидимым.

Проверка 5: проследите один запрос и его ответ

Не начинайте с браузера, потому что браузер скрывает, какой участок отказал. Проследите поток на концентраторе и прочитайте результат, прежде чем что-либо менять.

packet-tracer input outside tcp 198.51.100.25 50000 203.0.113.20 443 detailed
show nat detail
show xlate
show vpn-sessiondb l2l

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

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

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