VPN пое DNS и счупи локалните имена: поправете списъка

Тунелът се вдига, интранетът се зарежда, а името на принтера спира да се резолвва. Или обратното: локалните имена още работят, докато всичко в корпоративната мрежа изтича по време. И двата симптома идват от едно място — списък с резолвери, който VPN клиентът е пренаписал при свързване.

Поправете списъка нарочно, после се заемете отделно с механизма за push. Маршрутите са трета тема и не са тази, която се поправя тук.

Кой списък всъщност ползват приложенията

Windows резолвва чрез настройки на ниво интерфейс, а не чрез това, което показва някой диалог, затова започнете с ефективните списъци за всеки интерфейс. Псевдонимът е по-важен от показваното име, защото всяка команда по-долу се обръща към интерфейс. Сбъркате ли псевдонима, поправката ще попадне на грешния адаптер. Ще изглежда, че работи до следващото повторно свързване, когато записът на тунела се върне.

Въпросът е кои сървъри са се озовали отпред и дали са дошли като статични записи или като DHCP lease. И двата факта решават коя поправка ви е достъпна.

netsh interface ipv4 show dnsservers
Get-DnsClientServerAddress -AddressFamily IPv4

Прочетете изхода за адаптера на тунела и за физическия и отбележете всеки адрес на всеки от тях. Статичен запис може да се премахне с политика или скрипт; записът от DHCP е вързан към lease и ще се върне, което променя поправката, която трябва да изберете. Имената в отдалечената мрежа се резолвват от обявения резолвер, имената в локалната 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 под регистърния ключ на интерфейса, така че редакция в регистъра е последна мярка, която трябва да се провери отново след следващия lease. Редът на свързване на адаптерите също не е надежден механизъм за класиране, защото 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 настройка. Запишете псевдонима на интерфейса и адресите, на които сте се спрели, защото и двете се различават между машини и нито едно не оцелява при преустройство само по себе си.