Перевірка IP-потоку Azure каже «дозволено», але VPN усе одно не працює

Тунель «сайт — сайт» підключено, віртуальна машина здорова, але локальний клієнт нічого не отримує. Ви відкриваєте Network Watcher, запускаєте перевірку IP-потоку, і вона каже Access allowed, тож заявку закривають як проблему VPN. Цей результат означає не те, чим здається, бо перевірка IP-потоку оцінює правила безпеки для описаного вами потоку й ніколи не перевіряє, чи має Azure маршрут до вашого локального префікса.

Питання фільтрації та питання маршрутизації розділені, і Network Watcher відповідає на них різними інструментами. Розуміння того, яке саме питання ви поставили, — більша частина діагностики.

Що насправді вирішує перевірка IP-потоку

Перевірка IP-потоку бере віртуальну машину, мережевий інтерфейс, напрямок, значення п’ятірки й протокол, а потім повідомляє рішення правила NSG і адміністратора безпеки для цього потоку. Вона працює на TCP і UDP, тому не є тестером правил ICMP, і заблокований ping нічого не доводить про вашу службу. Дайте їй реальний потік, а не здогад. Вхідне з’єднання з локального середовища до порту бази даних — це інший опис, ніж вихідне з’єднання, яке ініціює віртуальна машина.

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

Чого вона не може сказати, то це який маршрут обрав Azure, чи пропускає гостьовий брандмауер порт і чи щось слухає. Це живе на інших рівнях.

Що додають наступний перехід і чинні маршрути

Наступний перехід відповідає на питання пересилання: для цього призначення який тип наступного переходу обирає Azure, за якою адресою, з якої таблиці маршрутів. Чинні маршрути перелічують те, що NIC справді має. Запустіть обидва, і ви отримаєте шлях на боці Azure, який зелена перевірка IP-потоку лишає порожнім.

Огляд перевірки IP-потоку від Microsoft прямо вказує обсяг фільтрації, а сторінки про наступний перехід і діагностику маршрутів охоплюють бік пересилання. Цитуйте правильну сторінку, коли записуєте висновок.

Команди достатньо короткі, щоб запускати їх із оболонки. az network nic show-effective-route-table перелічує маршрути, застосовані до інтерфейсу. az network watcher show-next-hop з джерелом і призначенням повертає вибраний перехід. Порівняйте потрібний вам префікс із цією таблицею, потім підтвердьте, який запис перемагає.

Пройдіть зворотний шлях від NIC віртуальної машини

Робіть це з NIC цільової віртуальної машини, для префікса локального клієнта, а не для інтернету. Зворотний шлях — це місце, де ховаються несправності «сайт — сайт», бо перевірка стану тунелю лише повідомляє, що асоціації безпеки підняті.

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

Читайте тип наступного переходу, а не копіюйте приклад

Шлях через керований шлюз VPN зазвичай показує VirtualNetworkGateway як тип наступного переходу. VirtualAppliance описує іншу схему пересилання, зазвичай брандмауер або віртуальний мережевий пристрій.

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

Перейдіть до межі, яка все ще не працює

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

Завершіть дозволеним запитом застосунку й спостереженнями з обох боків. Результат allow і правильний наступний перехід — це дві частини доказу, а не доказ того, що з’єднання вдалося.