Как моделировать поток VPN с помощью ASA packet-tracer

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

Разбор ниже предполагает, что ACL, правило NAT и контекст tunnel-group перед вами. Без них вывод описывает политику, которую вы не можете проверить.

Шаг 1: опишите внутренний поток простыми словами

Опишите приложение, прежде чем что-то вводить. Хост внутри, открывающий SSH к серверу за дальним шлюзом, — это один внутренний поток TCP с определённым портом источника. Именно этот поток оценивают ACL и фильтр VPN, поэтому именно его вы вводите.

Запишите его предложением и переведите поле за полем:

packet-tracer input inside tcp 10.30.0.25 53000 10.40.0.50 22 detailed

Шаг 2: выберите входной интерфейс и направление

Вход — это интерфейс, на который приходит пакет, а не тот, через который он уходит. Для хоста LAN, который инициирует, это интерфейс inside. Для обратного пакета той же сессии это интерфейс outside, и кортеж меняется на обратный. Записать пункт назначения как источник — второй по частоте способ получить убедительный, но ненужный ALLOW.

Порты тоже направлены. Порт службы относится к полю назначения при инициированном запросе, а эфемерный порт клиента — к полю источника. Модель с назначением TCP 500 описывает приложение TCP, слушающее 500; она не становится проверкой IKE только потому, что число появилось в команде.

Шаг 3: читайте фазы по порядку

Каждая фаза в выводе — решение со своим владельцем: поиск маршрута, ACL, NAT, затем выбор VPN или туннеля. Читайте их в напечатанном порядке и остановитесь на первой фазе, которая расходится с проектом.

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

Шаг 4: проверьте, какие обходы вы выбрали

Форма detailed принимает параметры, пропускающие проверки, и Cisco документирует параметр bypass-checks, охватывающий ACL, фильтр VPN, uRPF и проверки подмены IPsec. ALLOW, полученный с этими обходами, говорит, что маршрут и NAT работали бы, а не что политика пропустила бы реальный пакет. Запишите параметры рядом с результатом.

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

Шаг 5: закройте разрыв реальным обменом

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

Некоторые параметры trace и replay передают пакеты или сохраняют состояние. Следуйте документированному поведению для вашей версии и одобренной диагностической процедуры, а не трактуйте каждый вариант как запрос только для чтения.

Чего трассировка всё ещё не может сказать

Держите четыре вещи в одной заметке: кортеж, совпавшее правило NAT, туннель или политику, которая должна нести поток, и наблюдение, зависящее от направления. Без них более поздний инженер не отделит локальное решение политики от устоявшейся плоскости управления и от работающей службы. Первый сбой, за которым следует успех, тоже не доказывает, что туннель должен был подняться между ними; запишите фазу и изменение состояния.

Начните с внутреннего кортежа, остановитесь на первой фазе, противоречащей проекту, и только затем обратитесь к доказательствам с конечных точек. Трассировка — оракул политики, а не подтверждение доставки.