VPN S2S в Azure підключено, але трафіку немає: читаємо журнал IKE

Портал пише Connected, у тунелю є лічильник часу роботи, а трасування з вашої віртуальної машини вмирає на другому хопі. Стан з'єднання описує узгодження IKE і IPsec, а не те, чи виживає хоч один пакет на рівні політик з будь-якого боку. Більшість таких заявок пояснюють дві несправності, і жодну з них не виправляє зміна маршруту в Azure. Обидві вже записані в журналі, який створив шлюз, тому я починаю звідти, а не з таблиці маршрутів.

Що насправді засвідчує Connected

Підключене з'єднання site-to-site означає, що фази 1 і 2 завершено і асоціації безпеки піднято. Це твердження про узгодження: обидві сторони домовилися про пропозицію, обмінялися ключами й установили пару SA. Воно нічого не каже про те, чи збігаються селектори трафіку з підмережами, які ви вважаєте захищеними, і нічого про те, чи маршрутизуватиме далека сторона пакет кудись після розшифрування. Тунель може стояти тижнями, відкидаючи кожен цікавий потік, і саме ця схема змушує людей перебудовувати здоровий шлюз.

Дві несправності, які варто перевірити першими, — це партнер, що пропонує AH замість ESP, і віртуальна мережа, пронумерована в просторі, який шлюз не вважатиме внутрішнім.

Відкрийте експортований журнал, перш ніж чіпати маршрути

У порталі відкрийте шлюз віртуальної мережі та запустіть операцію VPN troubleshoot для з'єднання, потім завантажте створений пакет і розпакуйте його. Усередині журнал IKE з обмінами фаз 1 і 2, з позначками часу й читабельний як звичайний текст. Шукайте в ньому рядок transform, а не читайте згори вниз, бо цікавий запис зазвичай лежить за кількасот рядків. Якщо доступу до порталу немає, та сама діагностика з'являється в місці призначення журналів шлюзу, коли ввімкнено параметри діагностики.

Два записи несуть основну цінність. Перший звучить приблизно так: expected ESP with combined authentication and cipher, received AH. Другий — помилка неприпустимого payload під час обміну IKE, що зазвичай означає неправильно сформоване або непідтримуване поле пропозиції.

Обидва описують, що запропонував локальний пристрій, тож обидва є налаштуваннями на боці партнера. Перестворення боку Azure не змінює пропозицію, яку надсилає ваш міжмережевий екран, і робити це все одно — найчастіше змарнована година в цьому процесі. На партнері задайте фазу 2 в ESP з об'єднаною автентифікацією та шифром і дайте йому узгодити алгоритм, а потім перевірте, чи прапорець постачальника з назвою на кшталт combined mode тихо не вибирає пропозицію AH під ним.

Підтвердьте адресний простір віртуальної мережі

Шлюз очікує, що віртуальна мережа буде в приватних діапазонах. Мережа, пронумерована в публічному блоці, наприклад та, що починається з 111.x, може підняти тунель, але Azure відмовиться вважати цей простір внутрішнім, тож з'єднання виглядає здоровим, а жоден потік не приймається. Підтвердьте адресний простір, перш ніж витратити півдня на селектори. Якщо нумерація — жорстка вимога зі старого розподілу, виправлення полягає у зміні плану адрес, а не в іншому шлюзі.

Запишіть перекриття з локальними діапазонами, доки ви в колонці адресного простору, бо перекривані префікси дають іншу несправність, яка з боку клієнта виглядає схоже.

Перевірте префікси в обох напрямках

Ресурс шлюзу локальної мережі містить локальні префікси, і вони мають збігатися з підмережами, які далекий пристрій справді захищає. Зведення, що включає адреси, які пристрій відкидає, пропустить одні потоки і провалить інші, і це читається як періодична несправність маршрутизації, а не як невідповідність конфігурації. Перевірте і далекий бік: один кінець перелічує /16, а інший — три /24 усередині нього, це класична часткова відмова. Жоден список не є авторитетним сам по собі, тому порівняйте їх поруч, а не довіряйте тому, який бачите.

Зміна префікса не завжди підхоплюється сама, тому плануйте перезберегти або перестворити об'єкт з'єднання, а потім підтвердьте, що нові префікси з'явилися з обох боків.

Перевіряйте шлях, а не ping

Трасування, яке відрізняє робочий тунель від робочого маршруту, виглядає так: перший хоп — локальний шлюз, далі кілька хопів без відповіді, потім далекий хост відповідає. Якщо трасування так і не доходить до хоста, перевірте TCP-порт, який застосунок справді використовує, бо ICMP фільтрується досить часто, щоб невдалий ping доводив дуже мало. Запустіть те саме трасування з далекого хоста в бік віртуальної машини в Azure. Асиметрія між двома результатами — найшвидший спосіб знайти відсутній зворотний маршрут або правило, що дозволяє лише один напрямок.

Запишіть пропозицію партнера, обидва адресні простори й час створення з'єднання в заявку, щоб наступний інженер знав, які значення перебудовувалися, а які ніколи не чіпали.

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