Защо DNS спира да работи след свързване на OpenVPN под Windows

Резолверът още отговаря на ping, а порт 53 не стига доникъде. Проверете дали block-outside-dns филтрира, после осигурете резолвер, който тунелът да достигне.

Ping към офис резолвера все още получава отговор след свързване на "OpenVPN", а всяко търсене на име се проваля. Адресът е достъпен, а портът не, комбинация, която има смисъл, щом знаете, че Windows може да филтрира DNS по адаптер. С block-outside-dns в профила този филтър е първият заподозрян, а таблицата с маршрути е грешното място за търсене. Двата теста по-долу разделят слоевете за секунди.

Достъпен адрес, мъртъв порт

Успешният ping доказва, че хостът работи и има път. Той не казва нищо за разрешение към порт 53, защото въпросният филтър работи на друг слой и зависи от адаптера. Затова една и съща машина може да отговаря на ICMP и да отказва всяка заявка към същия адрес. Пуснете двата теста в една сесия, преди да променяте каквато и да е настройка.

ping <resolver-ip>
nslookup <name> <resolver-ip>

Двойката е диагнозата. Обикновеният трафик към подмрежата продължава да работи, докато имената не се разрешават, и хората заключават, че сървърът е счупен или че DNS никога не е бил изпратен. И двете обяснения са скъпи за проследяване, а доказателствата сочат към нещо по-тясно. Потвърдете двойката, преди да пипате настройка.

Опцията е правило на филтриращата платформа

Справката на OpenVPN описва block-outside-dns като ограничение на Windows Filtering Platform, което спира приложенията да достигат DNS по адаптери извън тунела. То покрива TCP и UDP порт 53. Понеже филтърът живее в WFP, а не в обикновения списък с правила на защитната стена, добавянето на разрешаващо правило другаде не променя непременно резултата. Затова общият съвет да се разреши DNS продължава да се проваля.

Настройката може да дойде от импортирания профил или от сървъра, а файлът, който последно редактирахте, "не е доказателство какво е заредил клиентът". Четете ефективната конфигурация и журнала за свързване заедно. Опцията е и специфична за Windows и третирането ѝ като преносима дава съвети, които не важат.

Търсете клиентския компонент, който притежава ограничението, вместо да добавяте още правила. Собственикът е това, което реално може да го премахне.

Филтърът не е резолвер

Блокирането на трафик извън тунела не инсталира работещ резолвер вътре в него. Опцията премахва път и оставя DNS конфигурацията на тунела на този, който е настроил профила. Профил, който никога не е изпращал резолвер, сега няма такъв изобщо.

Минете през три проверки по ред. Първо, кой резолвер действително ползва приложението, което се проваля. Второ, дали клиентът е приложил настройките за VPN DNS. Трето, кой интерфейс носи трафика към този резолвер.

  1. Резолвер в употреба: сравнете Resolve-DnsName -Server <resolver-ip> <name> с DNS сървърите, изброени от ipconfig /all.
  2. VPN DNS приложен: прегледайте DNS записите на тунелния адаптер в същия изход на ipconfig /all.
  3. Използван интерфейс: Find-NetRoute -RemoteIPAddress <resolver-ip> посочва изходящия интерфейс за тази дестинация.

LAN резолвер става недостъпен по дизайн при тази политика, дори докато друг LAN трафик работи. Това е опцията, която си върши работата. Ако дизайнът изисква VPN DNS, поправете регистрацията на резолвера и пътя на тунела; ако е нужен split DNS с локални изключения, собственикът на конфигурацията трябва да изрази тези изключения по поддържан начин.

Какво опцията не покрива

Порт 53 не е цялото разрешаване на имена. DNS over HTTPS и DNS over TLS използват различни транспорти, а някои приложения пускат собствена логика на резолвера независимо от системните настройки. Затова браузърът може да разрешава имена, а командният ред не.

Третирайте тази разлика като диагностика, а не като противоречие. Сравнете двете, преди да решите, че системният резолвер е счупен.

Дръжте извода тесен, когато го записвате. Тази опция ограничава един транспорт на една платформа, а останалата част от пътя на разрешаване е отделен въпрос на дизайн със свой собственик.

Проверете състоянието преди и след прекъсване

Пуснете същото търсене по време на връзката и отново след като клиентът собственик се изключи. Първото трябва да се провали за външен резолвер, докато тунелът е вдигнат, а второто трябва да успее, щом филтърът бъде премахнат. Ако след прекъсването то все още се проваля, филтърът не е бил изчистен.

ipconfig /displaydns
nslookup <name> <resolver-ip>

Рестартирането на клиентската услуга или на машината обикновено изчиства стар филтър. Това потвърждава диагнозата, без да доказва трайно решение. Запишете какво сте видели, защото филтър, който преживява прекъсване, ще го направи отново, и именно записът оправдава доклад за грешка.

Едва след тези проверки има смисъл да смените резолвера или да престроите политиката на защитната стена. И двете са по-големи промени, отколкото доказателствата подкрепят.

Подобни статии