Публикация внутреннего сервиса через VPN «сайт-сайт» на ASA
Пять упорядоченных проверок, чтобы открыть внутренний сервис через VPN «сайт-сайт» на ASA: защищённый диапазон, модель источника, трансляция, охват порта, путь ответа.
Публикация сервиса, который живёт за VPN «сайт-сайт», — одна задача с пятью точками отказа, и отказывают они в фиксированном порядке. Туннель поднимается, трансляция совпадает, филиал отвечает, и ответ возвращается тем же путём. Когда что-то из этого неверно, браузер показывает одно и то же: соединение, которое зависает или сбрасывается. Пройдите список сверху вниз и остановитесь на первой проверке, которая не прошла.
Проверка 1: туннель защищает адрес источника
Начните с туннеля, который уже пропускает трафик, затем убедитесь, что адрес, который вы собираетесь опубликовать, находится внутри защищённого диапазона. На ASA этот диапазон берётся из крипто-ACL или из маршрутов VTI, и он должен покрывать реальный адрес источника, а не подсеть, которую филиал использует для управления. Селектор, который промахивается мимо источника, даёт вам поднятый туннель и поток, который в него никогда не входит.
Подтвердите это счётчиками туннеля и таблицей маршрутов, прежде чем трогать трансляцию. Если источник недоступен с концентратора через туннель, ничто дальше в этом списке это не исправит.
Остановитесь здесь, если защищённый диапазон и адрес источника не совпадают.
Проверка 2: решите, какой источник увидит филиал
Филиал видит либо исходный адрес клиента, либо транслированный, и этот выбор определяет обратный путь. Сохранение адреса клиента читается чище в журналах источника, но тогда филиал должен отправлять ответы для публичных клиентов обратно через туннель; обычный интернет-маршрут по умолчанию отправляет их в другую сторону, и соединение умирает в одном направлении. Трансляция источника в адрес, который филиал уже маршрутизирует через туннель, убирает это требование.
Трансляция также меняет то, что источник может журналировать, и то, с чем могут совпадать правила на основе источника. Если приложению нужно знать человека за запросом, его место — в аутентифицированном обратном прокси, а не в решении NAT.
Проверка 3: пишите трансляцию под реальные интерфейсы
ASA оценивает правила трансляции по порядку и сообщает, какое совпало, поэтому пара интерфейсов внутри правила не косметика. Правило, написанное для пути снаружи внутрь, не совпадёт с потоком, у которого вход и выход отличаются от предполагаемых.
Путь, который вы строите, состоит из четырёх участков, и все четыре должны совпасть:
| Leg | Source | Destination |
|---|---|---|
| Request from the internet | 198.51.100.25 | 203.0.113.20:443 |
| After destination translation | 198.51.100.25 | 10.60.20.10:443 |
| After source translation toward the tunnel | 10.10.250.10 | 10.60.20.10:443 |
| Branch reply | 10.60.20.10 | 10.10.250.10 |
| Restored reply to the client | 203.0.113.20 | 198.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 неверна. Если она показывает отказ, порядок правил неверен. Если пакет доходит до туннеля, но источник никогда не отвечает, проблема в обратном пути филиала.
Затем отправьте один реальный запрос снаружи и подтвердите, что ответ возвращается через тот же туннель. Запишите опубликованную запись, трансляцию, защищённую пару адресов и обратный маршрут как запись публикации.