VPN перехопив DNS і зламав локальні імена: виправте список

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

Виправте список свідомо, а потім окремо займіться механізмом push. Маршрути — це третя тема, і не вона тут виправляється.

Який список застосунки насправді використовують

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

Питання в тому, які сервери опинилися попереду і чи прийшли вони як статичні записи або як оренда DHCP. Обидва факти визначають, яке виправлення вам доступне.

netsh interface ipv4 show dnsservers
Get-DnsClientServerAddress -AddressFamily IPv4

Прочитайте вивід для адаптера тунелю й для фізичного адаптера та запишіть кожну адресу на кожному з них. Статичний запис можна прибрати політикою або скриптом; запис, наданий DHCP, прив'язаний до оренди й повернеться, що змінює вибір виправлення. Імена у віддаленій мережі розв'язує оголошений резолвер, імена в локальній LAN — фізичний адаптер, а запит іде до списку, який переглядають першим.

Приберіть просунуті сервери або поставте їх нижче

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

netsh interface ipv4 delete dnsservers name="Corp VPN" address=all validate=no
netsh interface ipv4 add dnsservers name="Corp VPN" address=172.16.20.1 index=1 validate=no

Індекс 1 переглядають першим, тому просунуті адреси лишаються доступними, але перестають бути типовою відповіддю на кожен запит. Прапорець validate=no пропускає перевірку доступності, яка часто не проходить, поки тунель ще стабілізується, тож підтвердьте результат командою show, а не довіряйте коду виходу.

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

Де можна відфільтрувати push

Краще виправлення прибирає опцію до того, як її застосовано. Клієнт Community OpenVPN уміє фільтрувати просунуту директиву за назвою, і це залишає конфігурацію сервера недоторканою.

pull-filter ignore "dhcp-option DNS "

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

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

Зробіть виправлення стійким до перепідключення

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

Resolve-DnsName intranet.corp.example -Server 172.16.20.1
Resolve-DnsName printer.lan

Перепідключіть тунель і повторіть обидві команди. Те, що ви змінили вручну, тримається лише до наступного підключення, бо клієнт перебудовує стан резолверів, піднімаючи адаптер. Помістіть рядки netsh у підтримуваний скрипт підключення вашого клієнта, дайте скрипту успішно завершитися й додайте коротке очікування перед його запуском. Клієнт, який застосовує DNS після скрипта, все одно перезапише результат.

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