Зворотний трафік Azure P2S VPN працює лише в одному напрямку

Значок тунелю зелений, NSG виглядає дозвільним, чинні маршрути виглядають правильними, і все ж ВМ не може відкрити з’єднання назад до підключеного клієнта. Звичайне припущення полягає в тому, що робочий тунель point-to-site є симетричним: якщо клієнт дістає до ВМ, то й ВМ дістає до клієнта. Це припущення — помилка в міркуванні, а не в конфігурації. Тунель може пропускати один напрямок незапитаного потоку й відкидати інший, і виправлення залежить від того, який рівень його відкидає.

Міф: підключений тунель — це двонаправлений тунель

Тунель VPN — це шлях політики, а не дріт. Кожен напрямок зіставляється з селекторами, маршрутами й фільтрами, і будь-який із них може дозволити один напрямок, блокуючи інший.

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

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

Виберіть одну адресу клієнта, одну адресу ВМ і один протокол. Підключіться з клієнта й запишіть результат; потім почніть той самий тест із ВМ і теж запишіть. Якщо перший успішний, а другий ні, то пул клієнтів, зв’язок зі шлюзом і шлях від клієнта до VNet працюють.

Наступний крок — докази, а не нові правила. Перевірте NSG у підмережі ВМ в обох напрямках, прочитайте чинні маршрути на NIC ВМ і захопіть пакети на ВМ, поки клієнт надсилає трафік. Запит, що приходить без відповіді, — це проблема фільтра або зворотного маршруту; запит, що не приходить узагалі, — проблема шляху. Не вважайте невдалий ping доказом недоступності ВМ, бо політика ICMP може відкидати відповідь, поки TCP працює.

Зворотний шлях IKEv2 point-to-site — звичний підозрюваний

У звіті Azure, на якому ґрунтується ця стаття, клієнт діставав до ВМ через IKEv2, але вхідний ICMP від ВМ до клієнта не працював, доки тип тунелю шлюзу не перемкнули на OpenVPN. Автор звіту стверджує, що Microsoft підтвердила обмеження в шляху IKEv2 point-to-site: зворотний трафік від ВМ до клієнта не маршрутизується симетрично, якщо сеанс не почав клієнт. IKEv2 покладається на селектори трафіку, і шлюз у тому випадку не врахував зворотний напрямок.

Це не робить OpenVPN загалом кращим типом тунелю. Це робить тип тунелю змінною в матриці тестів для цього навантаження.

Зміна типу тунелю — це зміна служби, а не перемикач. Кожному клієнту потрібен сумісний профіль, а шлюзу може знадобитися інший сертифікат або налаштування автентифікації. Відтворіть однобічну поведінку з одним тестовим клієнтом і однією тестовою ВМ, змініть тип за затвердженим графіком і потім повторіть ті самі тести напрямку. Якщо поведінка зберігається після перемикання, тип тунелю не був причиною, і ви звузили проблему, не торкаючись продакшену.

Міф: виявлення через broadcast перетинає межу VNet

Друге припущення не справджується з не пов’язаної причини. Віртуальна мережа Azure не передає широкомовний трафік, тому ВМ не може отримувати широкомовні кадри з локальної мережі через з’єднання site-to-site або point-to-site. Застосунки, що знаходять партнерів через broadcast, як-от старий перегляд файлів або деякі протоколи виявлення пристроїв, ніколи не побачать віддалену сторону, хоч би як були написані маршрути.

Замініть виявлення через broadcast на імена DNS, службу каталогу або явний список партнерів. Якщо застосунок не має альтернативи unicast, проєкту потрібен інший механізм виявлення, а не ширший тунель.

Що змінити і як це довести

Якщо тест напрямку не проходить лише на IKEv2, запишіть тип тунелю шлюзу, пул адрес клієнтів і точний тест ICMP або TCP, а потім оцініть затверджений профіль OpenVPN для постраждалих клієнтів. Якщо він не проходить на будь-якому типі тунелю, працюйте зі зворотним шляхом: адреса клієнта має бути маршрутизованою з підмережі ВМ, кожен визначений користувачем маршрут має вказувати на дійсний наступний крок, а брандмауер клієнта має приймати вхідний потік. Додайте докази щодо NSG і маршрутів до заявки.

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