OpenVPN је послао DNS сервер, али Linux га игнорише

Послати DNS сервер је у дневнику, тунел је подигнут, а интерна имена и даље не успевају. У самом слању ништа није покварено; подешавање је стигло и ту се зауставило. Послата DNS опција је порука клијенту, а не упутство резолверу оперативног система, и управо је предаја између њих место где се завршава већина оваквих случајева. Пет провера, по реду, проналази предају која се није догодила.

Прва провера: како конекција почиње

Власник конекције одређује ко може применити подешавања резолвера. Директна openvpn команда из љуске не поседује ништа осим свог процеса, док systemd јединица, NetworkManager или клијент добављача свако има свој начин објављивања DNS-а. Прочитајте листу процеса и назив јединице пре него што претпоставите било шта од тога.

Процес из командне линије није аутоматски 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 извршава након што се привилегије спусте.

Уређивање скрипте резолвера дистрибуције ради промене њене излазне мете бележи заобилажење за једног домаћина. То није општа поправка.

Пета провера: исти резултат после поновног повезивања

Поново се повежите и поново прочитајте везу. Регистрација која се појави једном и нестане при следећем прелазу је квар због којег постоји цела ова контролна листа. Тестирајте после суспензије, после присилног поновног повезивања и после поновног покретања услуге резолвера. Сваки прелаз проверава другачију претпоставку о редоследу.

Тек када свих пет провера прође при поновном повезивању, можете рећи да се послата подешавања користе. Све пре тога је снимак срећног тренутка.