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, один дозволений потік на пару.

Якщо пара все ще не працює після відновлення, зміна не була причиною, і ви щойно зекономили собі другий простій.