FortiGate Azure перевипуск ключа: пропозиція peer SA не збігається з локальною політикою

Тунель піднявся, трафік пішов, а згодом у журналі з'являється peer SA proposal not match local policy. Більшість читають цей рядок як доказ того, що дві конфігурації ніколи не збігалися. Зазвичай він означає вужче: вони збігалися для першої CHILD SA і перестали збігатися під час першого оновлення, бо перша асоціація ніколи не потребувала обміну, який виконують наступні. Саме ця відмінність визначає, де шукати.

Перша CHILD SA успадковує, наступні домовляються

У IKEv2 початкова CHILD SA створюється під час IKE_AUTH, а її ключі виводяться з ключового матеріалу IKE SA. У цей момент окремого обміну Diffie-Hellman немає, тому група PFS, яку один peer не може прийняти, просто ще не перевіряється. Тунель виглядає здоровим, бо вимогу, на якій ви згодом провалитеся, ніколи не перевіряли.

Перевипуск ключа CHILD_SA — це інша послідовність повідомлень. Коли PFS налаштовано, peer виконують новий обмін ключами і мають домовитися про групу, прийнятну для обох сторін, а також про пропозицію ESP для нової асоціації. Саме в цей момент невідповідність стає видимою, і тому помилка називає пропозицію, а не маршрут.

Тож «учора працювало» нічого не каже про пропозицію. Воно каже, що початковий обмін вдався, що ви й так знали.

Читайте невдалий обмін, а не перший ping

Перш ніж щось змінювати, зберіть з обох боків успішну автентифікацію IKE, початкову CHILD SA і невдалу заміну. Потім назвіть операцію точно: перевипуск ключа IKE SA, повторна автентифікація IKE і перевипуск ключа CHILD SA — це три різні події, а «фаза 2» у звичайній мові охоплює їх усі.

Порівняйте поля нижче для з'єднання, яке не вдалося, а не для тунелю загалом.

На FortiGate відкрийте пропозицію фази-2, налаштування PFS і прийняті групи DH для цього тунелю. Читайте завантажені значення, а не виводьте їх із з'єднання, встановленого раніше. Знімок екрана сторінки GUI — слабший доказ, ніж робоча конфігурація, бо після оновлення вони можуть розійтися. Експортуйте змінений розділ і збережіть його разом із тікетом.

Політика Azure за замовчуванням — усе ще політика

Відсутність користувацької політики, прикріпленої до з'єднання, не означає, що Azure не застосовує жодної. З'єднання повертається до типового набору пропозицій шлюзу, який може бути ширшим або вужчим за те, що пропонує ваш FortiGate. Якщо набори перетинаються для IKE, але не для ESP з PFS, ви отримуєте саме таку картину відмови.

Це подання лише для читання показує фактично прикріплену політику, не розкриваючи секретів:

Get-AzVirtualNetworkGatewayConnection -Name 'Branch' -ResourceGroupName 'NetworkRG' |
Select-Object Name, ConnectionStatus, IpsecPolicies

Використовуйте справжні назви своїх ресурсів. Коли потрібна явна політика, задайте її на ресурсі з'єднання. Це не перемикач для всього шлюзу, і вона не застосовується тихо до інших тунелів на тому самому шлюзі.

На порталі сторінка Configuration цього з'єднання — це місце, куди поміщають користувацьку політику IPsec/IKE. Посібник Microsoft з користувацьких політик перелічує підтримувані параметри та вимоги до SKU. Azure бере одну повну комбінацію на з'єднання, тому поля IKE і поля IPsec задають разом, а не по одному.

PFS — це вимога, а не перемикач, який можна клацнути

Якщо ваша базова лінія безпеки вимагає PFS, рішення — група, яку приймають обидва peer з обох боків, виражена через відповідну політику. Вимкнення PFS, щоб помилка зникла, змінює властивість безпеки, яку ви намагалися зберегти, і зазвичай пізніше повертається як інша невідповідність.

Одна пастка, характерна для Azure: коли ви вибираєте GCM для ESP, вибір шифрування й цілісності має називати той самий алгоритм GCM і ту саму довжину ключа. Змішування шифру GCM з окремим алгоритмом цілісності дає комбінацію, яку служба відхиляє, і це виглядає як невідповідність peer, доки уважно не прочитаєте політику.

Виберіть найсильнішу комбінацію, яку підтримують обидва кінці і яку дозволяє ваша вимога, а потім запишіть її в журнал змін. Наступна людина порівнюватиме із цим записом, а не зі спогадом про робочий тунель. Внесіть туди групу PFS і пропозицію ESP, а не лише назву політики. Коли хтось згодом запитає, чому аудит не вдався або чому перевипуск ключа повільний, цей рядок відповість на обидва питання.

Перевірте обмін, який не вдався

Плануйте зміну зі шляхом відновлення, бо редагування політики може перервати тунель, який ви намагаєтеся виправити. Після повернення трафіку дочекайтеся оновлення CHILD_SA або викличте його і підтвердьте, що нова асоціація встановлена з передбаченою групою PFS. Потім підтвердьте, що трафік застосунків продовжується через неї.

Два хибні сліди варто назвати. Час життя SA — це локальні специфікації, тож нерівні значення нормальні, і їхня зміна лише зсуває момент появи проблеми. DPD визначає, чи живий peer; підвищення його тайм-ауту не вирівнює вибір ESP або PFS.

Запишіть узгоджений результат і наступну подію після зміни. Якщо з'єднання тепер не проходить до завершення автентифікації IKE, ви дивитеся на налаштування IKE, які щойно редагували, а не на початкову відмову оновлення CHILD.