Cisco ASA → Azure VPN: пары префиксов селектора трафика

Туннель поднимается, IKE выглядит здоровым, а через него ничего не идёт. Это обычная форма проблемы селектора ASA–Azure, и поэтому я пишу контракт до того, как трогаю любую из консолей. Контракт — это четыре вещи: объекты, идентифицирующие каждого пира, модель соединения, точные пары префиксов и проверка, доказывающая каждую пару. Ошибётесь здесь — и каждая последующая команда будет отлаживать конфигурацию, которую вы не должны были строить. Этот runbook — порядок, который я использую, вместе с командами, показывающими, какой объект на самом деле неверен.

Запишите четыре объекта до настройки

Начните с версии и платформы ASA, публичной конечной точки, типа и SKU шлюза Azure VPN и локального сетевого шлюза, представляющего вашу сторону. Эти четыре имени — словарь для всего последующего, и у каждого свой владелец, когда что-то ломается.

Если два из них всё ещё догадки, остановитесь. Неверный список префиксов на локальном сетевом шлюзе — не проблема настройки.

Выберите одну модель соединения и перестаньте смешивать шаблоны

Схема с crypto map и схема с tunnel interface — разные конфигурации, и шаблон одной не становится действительным для другой от изменения адреса пира. Запишите, какую вы строите, прежде чем что-либо вставлять, потому что несоответствие позже проявится как проблема селектора, а не как ошибка конфигурации. Руководство по совместимости ASA от Microsoft охватывает оба шаблона и указывает, какую модель шлюза Azure предполагает каждый. Если в ваших заметках модель не названа, схемы ещё нет.

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

Ограничения версий тоже входят в контракт. Старый отчёт с места об ограничении доменов шифрования — это данные о конкретных версиях, а не постоянное свойство каждого ASA.

Перечисляйте пары префиксов, а не агрегаты

Напишите матрицу. Из локальных A и B в Azure X и Y — четыре пары, и каждой нужно покрытие или явное исключение. Объединение A и B в один агрегат включает и всё, что находится между ними, и так схема тихо обзаводится дырой.

Проверяйте, о чём договорились пиры, а не то, что вы сохранили. Список локальных и удалённых сетей на ASA — это намерение; CHILD SA — результат.

Когда пары не хватает, исправление обычно — строка access-list или запись селектора, а не новый туннель.

Проверяйте командами, которые называют объект

На ASA подтвердите сеанс IKE, затем SA IPsec, затем пары селектора. Каждая команда отвечает на свой вопрос, и запуск только первой — это способ превратить «туннель поднят» в ложный вывод. Читайте вывод для пира, который вы действительно настроили, а не для SA, случайно оказавшегося первым в списке. Сторона Azure отвечает на те же три вопроса со своей точки зрения.

show crypto ikev2 sa detailed
show crypto ipsec sa peer 203.0.113.10
show run access-list AZURE-SELECTORS
packet-tracer input inside icmp 10.1.10.10 8 0 10.2.20.20 detailed

Затем спросите Azure о состоянии подключения через az network vpn-connection show --name <connection> --query connectionStatus. «Подключено» при нуле байт в пути данных — проблема селектора, а не маршрутизации.

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

Держите область шифрования отдельно от разрешения доступа

Широкий селектор — не разрешение. Если поддерживаемая схема шире политики приложения, оставьте узкие сервисы в правилах firewall, а область шифрования там, где она должна быть.

Маршруты рабочих нагрузок Azure и локальные обратные маршруты рассматриваются отдельно. Объявления BGP, статическая область сети и определяемые пользователем маршруты должны описывать один и тот же путь, и ни один из них не может рекурсивно захватывать транспорт пира.

Откат и доказательство, что он сработал

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

Если пара всё ещё не работает после восстановления, изменение не было причиной, и вы только что сэкономили себе второй простой.