Azure P2S VPN не може розв'язати ім'я приватної кінцевої точки

Ви підключаєте тунель point-to-site, пінгуєте приватну адресу, відкриваєте застосунок і натомість отримуєте 403 або помилку сертифіката. Обидва симптоми вказують на DNS, але це різні несправності: одна означає, що клієнт розв'язав публічну адресу, друга — що він розв'язав приватну адресу і потім запропонував ім'я, яке сертифікат не покриває. Пройдіть наведені нижче перевірки по порядку і зупиніться на першій невдачі, бо запис у hosts або відповідь із кешу можуть змусити кожну наступну перевірку пройти з неправильної причини. Я тримаю цей порядок у текстовому файлі поруч зі своїми профілями VPN, бо виправлення нічого не змінює в тунелі й усе змінює в тому, що знає клієнт.

Почніть з адреси, яку клієнт справді отримує

Запитайте резолвер напряму, замість того щоб довіряти застосунку. У Windows nslookup adminuidev-fedqcubyd9bfb2bq.canadacentral-01.azurewebsites.net показує, яке подання отримав клієнт. Публічна відповідь означає, що далі ніщо не досягне кінцевої точки; приватна адреса кінцевої точки означає, що DNS завершено і наступна перевірка — сам зв'язок.

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

Перевірте зону, її прив'язку та запис до тунелю

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

Імена зон належать службам, а не приватним зв'язкам загалом. App Service зазвичай використовує privatelink.azurewebsites.net, у сховища й SQL свої простори імен, а позичання зони іншої служби дає зону, яка існує й не відповідає нічого корисного.

Дайте клієнту резолвер, до якого він справді дістанеться

168.63.129.16 відповідає з віртуальних машин Azure і не є DNS-сервером для ноутбука з іншого боку тунелю point-to-site. Клієнту потрібен резолвер, доступний через тунель: вхідна кінцева точка Azure DNS Private Resolver, пересилач усередині віртуальної мережі або записи DNS-сервера, перенесені в профілі клієнта VPN, щоб клієнт питав віртуальну мережу напряму.

Налаштований, але недоступний резолвер поводиться точно як відсутність резолвера, і симптом — тайм-аут, а не неправильна відповідь, тому його помилково читають як проблему брандмауера. Перевіряйте його запитом, який тунель має переносити, а не публічним ім'ям, яке все одно пройшло б локальним з'єднанням.

Якщо ви пересилаєте, а не проштовхуєте налаштування, пересилайте простір імен, що належить приватній зоні, privatelink.azurewebsites.net, а не весь azurewebsites.net. Умовний пересилач, який ковтає весь батьківський суфікс, надсилає в Azure кожен пошук служби, включно з тими, що мають залишитися локальними.

Використовуйте ім'я, для якого видано сертифікат

Коли адреса правильна, проявляється друга несправність. Сховище й App Service публікують псевдонім privatelink, і цей псевдонім не обов'язково є ім'ям у сертифікаті. Завантаження AzCopy на privatelink.blob.core.windows.net не пройшло перевірку; те саме завантаження на <account>.blob.core.windows.net/<container> розв'язалося в приватну адресу й пройшло, тож воно залишилося на приватному шляху без жодного обходу.

Правило діє в браузері й для App Service: підключайтеся за ім'ям вузла, яке покриває сертифікат, і дозвольте DNS надати приватну адресу. Не вдавайтеся до обходу перевірки, бо він перетворює помилку в найменуванні на регресію безпеки. Успішний ping доводить маршрут і нічого не каже про ім'я всередині рукостискання, тому це залишається окремими перевірками.

Порядок із чотирьох кроків, що ізолює кожен шар

1. Підтвердьте, що клієнт VPN має адресу з пулу point-to-site і маршрут до приватної адреси кінцевої точки.
2. Розв'яжіть точне ім'я, яке використовує застосунок, і порівняйте відповідь з адресою кінцевої точки.
3. Відкрийте TCP-з'єднання з кінцевою точкою на порту служби, потім прочитайте ім'я сертифіката, пред'явленого в цьому з'єднанні.
4. Лише тепер перевіряйте авторизацію, бо робочий маршрут і чинний сертифікат ще не дають доступу до ресурсу.

Відмова в з'єднанні при правильній адресі вказує на групу безпеки мережі або стан підключення приватної кінцевої точки, а не на DNS, тож перевірте їх, перш ніж знову правити налаштування резолвера. Розбіжність імені TLS повертає вас до імені вузла в URL і subject сертифіката. Тримайте разом вивід розв'язання, ім'я сертифіката й точний URL; ці три значення пояснюють більшість таких випадків, не торкаючись шлюзу.

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

Клієнти теж кешують. Запис, що публічно відповів десять хвилин тому, продовжує відповідати й після виправлення зони, тож очистьте кеш перед повторною перевіркою. У Windows ipconfig /flushdns очищає кеш клієнта; правила політики розв'язання імен залишаються, визначають, який суфікс іде до якого сервера, і можуть далі надсилати простір імен резолверу, який ви щойно замінили.

Де місце запису в hosts

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

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

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