VPN-з'єднання Windows не зберігає DNS-сервери в профілі, який ви редагуєте в Параметрах. Коли тунель піднімається, клієнт узгоджує IP-конфігурацію зі шлюзом, шлюз надсилає список резолверів, а Windows застосовує його до адаптера тунелю. Цей адаптер — окремий інтерфейс від вашого Wi-Fi чи Ethernet, і список належить інтерфейсу, а не профілю. Коли ви знаєте, який об'єкт володіє значенням, перевизначити його в PowerShell — одна команда; змусити перевизначення пережити повторне підключення — це та частина, що потребує рішення.

Який об'єкт володіє адресою

RAS створює адаптер тунелю, коли з'єднання успішне, і видаляє його, коли з'єднання падає. DNS-сервери, які ви бачите в ipconfig /all, надходять під час цього обміну конфігурацією, поруч з адресами IPv4 і IPv6 та маршрутами. Оскільки значення прив'язане до інтерфейсу, Set-DnsClientServerAddress пише в те, що існує лише поки існує з'єднання.

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

Знайдіть псевдонім, перш ніж чіпати DNS

Ім'я профілю та псевдонім інтерфейсу зазвичай збігаються як рядок, але це не той самий об'єкт. Get-VpnConnection виводить профілі; Get-NetAdapter виводить інтерфейси, які Windows справді має. Командам cmdlet DNS потрібен другий, і ці двоє розходяться частіше, ніж люди очікують, особливо коли клієнт додає до імені адаптера опис на кшталт "(RAS)".

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

Add-VpnConnection -Name "Corporate" -ServerAddress vpn.example.net `
  -TunnelType Ikev2 -EncryptionLevel Required `
  -AuthenticationMethod Eap -AllUserConnection

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

rasdial.exe "Corporate"
Get-NetAdapter | Where-Object InterfaceDescription -like "*VPN*"
Get-DnsClientServerAddress -InterfaceAlias "Corporate"

Застосовуйте перевизначення в правильному порядку

Порядок важливіший за синтаксис. Адаптер має бути піднятий, псевдонім має розв'язуватися, а обліковому запису має бути дозволено змінювати параметри інтерфейсу. Підключення на користувача зазвичай приймає зміну від користувача, який увійшов; підключення для всіх користувачів, створене з -AllUserConnection, зазвичай потребує підвищеної оболонки.

Сам cmdlet — один рядок, задокументований у довідці Set-DnsClientServerAddress від Microsoft:

Set-DnsClientServerAddress -InterfaceAlias "Corporate" -ServerAddresses 10.20.0.53,10.20.0.54
Get-DnsClientServerAddress -InterfaceAlias "Corporate" -AddressFamily IPv4

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

Чому повторне підключення може скасувати зміну

Перевизначення належить одному екземпляру інтерфейсу. Коли клієнт зносить адаптер і перестворює його під час наступного підключення, надіслані значення застосовуються знову, і ваш список зникає. Одні клієнти перестворюють інтерфейс при кожному підключенні; інші використовують його весь час сеансу. Порівняйте індекс інтерфейсу в Get-NetAdapter між двома підключеннями, і ви дізнаєтеся, яка поведінка у вас.

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

Внутрішні імена з однією міткою теж потребують списку пошуку суфіксів. Set-DnsClientGlobalSetting -SuffixSearchList діє на всю машину, тому змінює розв'язання для кожного адаптера на комп'ютері, включно з Ethernet. Перевірте його на лабораторній машині, перш ніж воно потрапить в образ.

Перевіряйте розв'язання, а не лише налаштування

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

Resolve-DnsName server01.corp.example -Server 10.20.0.53
Resolve-DnsName server01.corp.example

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

Запустіть тест двічі: один раз одразу після підключення і один раз після відключення та повторного підключення, і порівняйте вивід Get-DnsClientServerAddress з обох запусків. Якщо надіслане значення повернулося на другому підключенні, перевизначення жило й померло разом з адаптером, і втримається лише правило NRPT або маршрут політики з попереднього розділу. Збережіть обидві розшифровки та часові позначки підключення; вони вирішують питання, чи зберігається налаштування, швидше, ніж ще один круг правок.

Схожі статті