Чому приватна кінцева точка досі відповідає публічною адресою

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

Почніть із розв'язувача клієнта

Запитайте клієнт, до якого сервера він звертається, поки тунель піднятий. Профіль «точка-до-сайту» надає цю адресу, а профіль, який нічого не надає, залишає операційній системі повернення до типових значень адаптера.

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

Прочитайте, якою є відповідь насправді

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

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

Запис у hosts доводить шлях, а потім бреше

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

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

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

Зв'яжіть зону та видайте розв'язувач

Дві умови мають виконуватися одночасно. Приватна зона має бути прив'язана до віртуальної мережі, де живе кінцева точка, а клієнт має надсилати запити на сервер, який уміє читати цю зону. Вхідна кінцева точка DNS Private Resolver надає таку адресу всередині мережі й відповідає на запити, що надходять через тунель. Помістіть цю адресу в профіль VPN і додайте приватний суфікс, який клієнт має застосовувати.

Уже наявний локальний розв'язувач може досягти того самого результату через умовну пересилку, спрямовану на зону.

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

Перевіряйте ім'я, порт і ідентичність по черзі

Працюйте по черзі: розв'яжіть ім'я, підтвердьте, що відповідь приватна, відкрийте порт, а потім виконайте автентифікований запит. Кожен етап має свого власника та свій підпис відмови.

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

Ще одна відмова входить до цього списку. Міжмережевий екран служби, що дозволяє адресу клієнта, перестає збігатися, коли пул після перепідключення віддає цю адресу іншій сесії. Читайте адресу викликача, записану службою, а не ту, яку клієнт вважає своєю. Ці дві розходяться частіше, ніж люди очікують. Настанови Azure DNS Private Resolver описують зв'язок зони та схему пересилки.