OpenVPN изпраща DNS сървър, но Linux го игнорира

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

Проверка първа: как започва връзката

Собственикът на връзката определя кой може да приложи настройките на резолвера. Директна команда openvpn от шел не притежава нищо освен собствения си процес, докато systemd unit, NetworkManager или клиент на доставчик всеки има свой начин да публикува DNS. Прочетете списъка с процеси и името на unit-а, преди да приемете някое от тях.

Процес от командния ред не е автоматично връзка на NetworkManager, а връзка на NetworkManager не е автоматично това, което е записало resolv.conf. Тези две допускания обясняват повечето от пропиляните часове в това разследване. Попитайте кой компонент би публикувал DNS за интерфейса, който действително виждате.

Запишете собственика, преди да продължите. Всяка следваща проверка зависи от него.

Проверка втора: какво всъщност съдържа връзката на резолвера

На хост със systemd-resolved resolvectl status изброява всяка връзка с нейните DNS сървъри и домейни. Намерете връзката на тунела и прочетете записите ѝ, и не предполагайте, че интерфейсът се нарича tun0, защото номерацията следва реда на създаване. Ако изпратеният адрес липсва във връзката, предаването се е провалило, а не заявката.

Ако адресът присъства, следващият въпрос е кои домейни претендира тази връзка. Връзка без списък с домейни отговаря само на имена, за които е питана директно, а това рядко е, което иска едно split-DNS внедряване. Адресът сам по себе си е необходим, но не е достатъчен.

Сравнете името на връзката в изхода на резолвера с името на интерфейса в журнала на VPN, преди да правите каквото и да е заключение. Несъответствие там обикновено означава, че редът в журнала е дошъл от друг процес.

Проверка трета: дали пространството от имена избира тази връзка

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

Проверете присвояването на домейн, не само адреса на сървъра. Домейн, записан като ~corp.example, е маршрутен домейн и тилдата променя начина, по който се съпоставя името.

Ако приложението има свой резолвер, тествайте със същия механизъм, който то използва, а не със системния инструмент. Инструмент за заявки, който заобикаля системния резолвер, ще успее независимо от състоянието на връзката.

Проверка четвърта: един собственик, не двама

Ако NetworkManager вече управлява VPN и състоянието на резолвера, добавянето на несвързан hook скрипт създава конкуриращи се писатели. Hook-ът, предоставен от пакета за systemd-resolved, е поддържана интеграция и очаква определен жизнен цикъл: script-security 2, път up, up-restart, път down и down-pre. Тези опции карат регистрацията и премахването да се случват в правилните моменти, а не само при първата връзка.

Използвайте инсталирания път от пакета, а не илюстративен, копиран от ръководство. Правата също имат значение, защото hook-ът се изпълнява след отпадането на привилегиите.

Редактирането на резолверен скрипт на дистрибуцията, за да смените целта на изхода му, документира заобикаляне за един хост. Това не е общо поправяне.

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

Свържете се отново и прочетете връзката наново. Регистрация, която се появява веднъж и изчезва при следващия преход, е отказът, за който съществува целият този контролен списък. Тествайте след заспиване, след принудително повторно свързване и след рестарт на услугата на резолвера. Всеки преход упражнява различно допускане за реда.

Само когато и петте проверки минат при повторно свързване, можете да кажете, че изпратените настройки се използват. Всичко по-рано е снимка на щастлив момент.