Azure «точка — сайт» підключається, але жоден приватний ресурс не відповідає

Підключено — це стан тунелю, а не твердження про доступність. Клієнт «точка — сайт» може завершити IKE, отримати адресу і все одно нікуди не потрапити, бо шлюз передає трафік лише для мереж, які VNet уже знає. Виконайте ці п'ять перевірок по порядку і зупиніться на першій невдачі. Перескакувати вперед — це спосіб годину лікувати проблему DNS як проблему міжмережевого екрана.

Порядок важливіший за список.

Перевірка 1: вирішіть, що тунель має передавати

Azure VPN Gateway завершує тунель і передає трафік, що належить VNet; це незагальний вихід в інтернет. Якщо користувачі очікують, що їхній перегляд піде через Azure, проєкт хибний ще до того, як у справу вступить будь-яке налаштування клієнта. Увімкніть split tunneling, щоб локальний інтернет залишався на локальному шляху, а екземпляр NAT або тунель «сайт — сайт» використовуйте, коли справді потрібна фіксована адреса виходу.

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

Перевірка 2: порівняйте адресні простори до сертифікатів

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

Автентифікація — наступна брама. Профілі сертифіката, RADIUS і Entra ID не взаємозамінні, і клієнтський пакет для кожного різний.

Перевірка 3: розв'яжіть приватне ім'я зсередини

Клієнт зберігає власний resolver, якщо лише завантажений профіль не містить DNS-серверів VNet, а цей список вбудовується під час завантаження. Додайте forwarder усередині VNet, призначте його DNS-сервером VNet, потім знову завантажте й імпортуйте клієнтський пакет. Повторне використання старого пакета перевіряє лише старий список resolver-ів.

Спочатку перевірте адресу, бо це одним кроком відокремлює маршрутизацію від імен: Test-NetConnection 10.20.1.4 -Port 3389.

Якщо адреса відповідає, а ім'я ні, запитайте resolver напряму командою Resolve-DnsName files.corp.example -Server 10.20.0.4. Якщо не працює й те й те, несправність не в DNS, і вам варто припинити змінювати налаштування DNS. DNS платформи Azure за адресою 168.63.129.16 відповідає лише зсередини VNet, тому клієнт ззовні не може використовувати цю адресу як resolver.

Перевірка 4: перевірте службу за тунелем

Здоровий тунель і закритий порт з боку клієнта виглядають однаково. Перевірте міжмережевий екран гостьової системи, потім групу безпеки мережі на підмережі або NIC, потім те, чи слухає служба приватну адресу, а не лише loopback. Дозвольте пул клієнтів як джерело замість відкриття правила в інтернет і пам'ятайте, що SMB до Azure Files потребує, щоб шлях приватної кінцевої точки йшов через тунель. Коли ресурс відповідає за IP, але не за іменем, поверніться до перевірки 3, а не чіпайте шлюз.

Одна таблиця розділяє рівні під час роботи:

Перевірка 5: зафіксуйте профіль до ескалації

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

Для невеликої команди стійкий проєкт — це один VNet, один DNS-forwarder і задокументований клієнт із split tunneling. Якщо вимога — фіксований публічний вихід, завершіть тунель «сайт — сайт» на міжмережевому екрані, який ви контролюєте, і спрямуйте інтернет-трафік туди, замість просити шлюз «точка — сайт» робити те, для чого він ніколи не створювався.