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

Одне налаштування, одна служба й одна роль; три джерела, три перемикачі.

Почніть із запису, а не з прапорця

Запитайте повне ім’я постраждалого сервера через DNS-сервер, яким клієнти справді користуються, і запишіть кожну повернену адресу. Зіставте кожну повернуту адресу з реальними інтерфейсами ЛМ та тунелю сервера і з мережами, у яких перебувають клієнти. Адреса може бути цілком придатною локально і водночас недоступною для важливих клієнтів. Періодичні збої автентифікації — частий симптом, бо клієнти в різних спробах отримують або вибирають різні адреси.

Те, що машина правильно розв’язує власне ім’я, доводить дуже мало. Вирішальна перевірка виконується з мереж клієнтів.

Адаптер — лише одне джерело

У властивостях TCP/IP адаптера є прапорець для реєстрації адреси цього з’єднання, і його зняття вимикає рівно одне джерело. Інші воно не зупиняє, тому запис може з’явитися знову після перезавантаження. Якщо контролер домену також виконує службу DNS, у цієї служби є власна конфігурація прослуховування та власні записи сервера імен. Настанови Microsoft для середовищ із кількома інтерфейсами розглядають поведінку інтерфейсу, службу DNS і Netlogon як окремі значущі джерела.

Три перемикачі, три власники, і лише один із них живе на сторінці властивостей адаптера.

У служби DNS є власні адреси

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

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

Спочатку власник, потім очищення

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

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

Запишіть, яке джерело було відповідальним, які записи змінилися і які клієнти перевірялися. Наступний сервер із кількома інтерфейсами матиме тих самих трьох підозрюваних.

Схожі статті