Чому Windows надсилає імена вашого VPN на DNS-сервер, який ви ніколи не налаштовували

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

Що ви змінили і що насправді вирішує

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

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

Як таблиця зіставляє ім'я

Правила індексуються за простором імен, і перемагає найточніший збіг. Правило для corp.example діє для vpn.corp.example і не діє для example.net. Правило з простором імен . охоплює все, чого не охоплюють інші правила, що робить його найнебезпечнішим записом у списку і тим, який варто перевірити, коли сторонній сайт розв'язується через тунель.

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

Читайте чинну таблицю, а не список бажань

Налаштовані правила і чинні правила — два різні питання. Get-DnsClientNrptRule перелічує те, що є в системі. Get-DnsClientNrptPolicy -Effective показує, що клієнт справді застосує, зі значеннями, об'єднаними з політики та локальних налаштувань.

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

Без правила Windows опитує більше одного адаптера

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

Є два виходи. Додайте правило для простору імен, щоб рішення перестало бути гонкою, або вимкніть паралельну поведінку через політику DNS-клієнта і прийміть повільніше, детерміноване розв'язання. Перше зазвичай краще підходить для VPN із розділеним тунелем, бо документує намір замість покладання на порядок.

Шляхи, що повністю обходять резолвер

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

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

Перевіряйте тим іменем, яке не спрацювало

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

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