Продукраният от OpenVPN DNS се игнорира: кой компонент го прилага

Логът показва опцията, която сървърът е прокарал, тунелът е вдигнат, а вътрешните имена все още се провалят. Директна заявка към резолвера отговаря, значи сървърът е наред, но всяко приложение продължава да пита локалния рутер. Това, което стига до клиента, е предложение, а не промяна в резолвера, и компонентът, който притежава разрешаването на имена, е различен на Linux, Windows и macOS. Щом отделите опцията от нейния собственик, четири дефекта покриват почти всеки доклад: липсва hook, два конкуриращи се hook-а, разделен DNS, работещ както е проектиран, или кратко име, което иска суфикс, а не сървър.

Продукраната опция е предложение, а не инсталация

На сървъра две директиви описват намерение, а не ефект:

push "dhcp-option DNS 10.8.0.1"
push "dhcp-option DOMAIN corp.example"

Клиентът не получава конфигуриран резолвер. Той получава променливи на средата, foreign_option_1 и следващи, по една за всеки прокаран ред, и нещо локално трябва да ги прочете и да презапише състоянието на резолвера в операционната система. На Linux по подразбиране нищо не прави това, затова правилен сървър и свързан клиент все още могат да разрешават имена през LAN.

Между двата края стоят три етапа: push трябва да стигне, клиентът трябва да го покаже, а hook трябва да го приложи. Четете средния етап в лога на клиента, а последния етап в състоянието на резолвера, никога обратното, защото ред от лога доказва само първите два.

Потвърдете, че push е пристигнал, и намерете собственика

Започнете с името на стартиращия: гола openvpn команда, инстанция на systemd, NetworkManager или клиент на доставчик. Това решава къде може да живее hook. На хост със systemd-resolved resolvectl status изброява всяка връзка със DNS сървърите и домейните за търсене, които наистина използва, а връзката на тунела не винаги се казва tun0.

Ако прокараният адрес се появи в лога, но не на никоя връзка, интеграцията липсва. Ако се появи на връзката, а заявките все още излизат другаде, проблемът е кои заявки избират тази връзка. NetworkManager dns=dnsmasq във файла /etc/NetworkManager/NetworkManager.conf стартира локален препращач, който прилага разделен DNS нарочно: имената в домейна на VPN отиват при резолвера на VPN, а всичко останало запазва предишния път. Такова поведение изглежда като дефект, когато сте очаквали целия трафик да се премести; проверете настройките за връзката с nmcli connection show "My VPN", където ipv4.dns и ipv4.dns-search държат стойностите зад това, което устройството съобщава, преди да го наречете счупено. Ако всяка заявка наистина трябва да стига до резолвера на VPN, премахнете dns=dnsmasq от NetworkManager.conf и рестартирайте NetworkManager, което връща разрешаването на имена на настройките на връзката; иначе запазете разделения DNS и коригирайте прокарания списък с домейни.

Linux: предайте опциите на резолвера

Дистрибутивните пакети носят hook за това и клиентът трябва да има разрешение да го стартира. Типично подреждане на хост без systemd-resolved:

script-security 2
up /etc/openvpn/update-resolv-conf
down /etc/openvpn/update-resolv-conf

Със systemd-resolved по-старият скрипт resolv.conf може да не промени нищо съществено, защото stub резолверът държи състояние за всяка връзка. update-systemd-resolved помощната програма документира форма на hook, която използва up-restart и down-pre, което има значение, когато интерфейс надживее един опит за свързване. Каквото и да изберете, един компонент трябва да притежава състоянието. Добавянето на несвързан hook до NetworkManager дава двама писатели на една и съща връзка и резултатът тогава зависи от подредбата, а не от конфигурацията ви.

Има и случая, в който NetworkManager напълно игнорира прокараната опция, докато адресът на сървъра не беше въведен в IPv4 настройките на връзката, след което състоянието на резолвера показа, че се използва. Струва си да се опита преди пренаписване на скриптове, защото премества проблема от shell hook към профила на връзката, който вече носи тунела.

Windows и macOS прилагат различни части

Клиентът за Windows наистина задава DNS сървърите на VPN адаптера, но Windows все още избира интерфейс по метрика и все още иска суфикс, за да разшири кратко име. Проверете състоянието на адаптера, а не профила:

Get-DnsClientServerAddress -InterfaceAlias "My VPN"
Get-DnsClientNrptPolicy

Ако адресът липсва, задайте го с Set-DnsClientServerAddress -InterfaceAlias "My VPN" -ServerAddresses 10.8.0.1, после добавете суфикса към IPv4 свойствата на адаптера, така че fileserver да стане fileserver.corp.example. Стойност SearchList за цялата машина под Tcpip\Parameters прави същото. Където дългото име се разрешава, а голото не, резолверът вече е наред и списъкът за търсене е виновен. Поправките, в ред: прокарайте DOMAIN за да научи клиентът суфикса, добавете този суфикс към списъка за търсене на адаптера или връзката, и като временна мярка заковарете името в hosts, или LMHOSTS на Windows; NetBIOS браузването не преминава през рутер, затова broadcast-ът, който намира кратко име в офис LAN, никога не стига до клиент на тунел.

block-outside-dns block-outside-dns е поведение на Windows клиента, не преносим ред в профил, и копирането му в Linux или macOS профил не го възпроизвежда там. Ако публичните имена работят, а вътрешните се провалят на Windows, сравнете реда на адаптерите в Advanced settings с ipconfig /all. На macOS редът на резолвера за услуга принадлежи на системата, затова използвайте scutil --dns , за да видите кой резолвер се пита за кой домейн, и третирайте всяка отделна препоръчана поправка на профила като зависима от клиента, а не обща.

Виртуална машина на същия лаптоп не наследява нищо от това. Дайте на госта собствен запис за резолвер за вътрешния домейн или оставете NAT на хипервизора да препраща заявките му през хоста, което е вярно само докато тунелът на хоста е вдигнат.

Историята е третата причина. DNS сървъри или настройки за суфикс от по-ранен профил могат да преживеят повторни свързвания, затова когато адаптерът изглежда наред, а търсенията все още се провалят, сравнете живия адаптер с Get-VpnConnection и изчистете или презапишете остарелия запис, преди да пипате сървъра.

Докажете къде е отишла заявката

Запис по време на едно търсене решава спора: tcpdump -ni eth0 port 53 показва заявки на физическия интерфейс, което значи, че те напускат извън тунела и резолверът никога не е бил превключен. dig @10.8.0.1 name.corp.example след това разделя двата останали случая. Ако директната заявка отговаря, резолверът работи и клиентът не го използва; ако изтече времето, резолверът е недостъпен през тунела и никаква локална промяна няма да помогне.

Ако резолверът, който още се използва, е този, който доставчикът е раздал, тунелът криптира трафика, докато имената остават видими за този доставчик. Това е въпрос за изтичане, а не функционален, и същият запис отговаря: заявка на физическия интерфейс отива към някого извън тунела.

Достъпността включва защитната стена на VPN хоста, която трябва да разрешава UDP и TCP 53 от пула. Затворен порт изглежда точно като счупен push, а също и резолвер, който отговаря само от вътрешността на тунелната мрежа. Повторете записа след едно прекъсване и повторно свързване, защото настройки, които се появяват при първото свързване и изчезват при второто, са дефект в жизнения цикъл на hook, а не липсваща опция.

Дръжте един собственик и проверявайте по ред

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

Затворете цикъла с четири проверки: прокараният адрес присъства на връзката на тунела, вътрешното име се разрешава като напълно квалифицирано име, същото име се разрешава без суфикса и двете са верни след едно повторно свързване. Един запис ви казва коя от четирите се е провалила. Ръководството за OpenVPN 2.6 изброява dhcp-option и скриптовите директиви с бележките им за платформи.