Неге resolv.conf VPN DNS-ін көрсетеді, ал іздеулер оны елемейді

Журналдарда ешнәрсе қате көрінбейді: интерфейс қосулы, шешуші VPN-нің DNS серверін хабарлайды, ал дискідегі файл оны тізімдейді. Соған қарамастан ішкі хост атауы әлі де жергілікті маршрутизатор арқылы шешіледі. Бұл үш тұжырым бір-біріне қайшы келмейді, өйткені файл, әр қосылымның күйі және іздеу жолы кездейсоқ бір атты бөлісетін түрлі нысандар. Төменде systemd-resolved бар хостта сұрау шын мәнінде жүретін жол сипатталған.

resolv.conf деп аталатын үш нысан

resolved бар хостта /etc/resolv.conf әдетте /run/systemd/resolve/stub-resolv.conf файлына символдық сілтеме болады. Бұл мақсатта жергілікті stub-тыңдаушының мекенжайы, 127.0.0.53, және resolved есептеген іздеу домендері бар. Бұл күйдің көрінісі, күйдің өзі емес.

Күй resolved-тің әр қосылым бойынша конфигурациясында өмір сүреді, сондықтан resolvectl status файлмен келіспесе де дұрыс болуы мүмкін. Әр қосылым өз серверлерін және өз маршруттау домендерін алып жүреді, ал stub сұрау келгенде сол деректерге жүгінеді. systemd-resolved нұсқаулығы жасалған файлдар мен әр қосылым үлгісін сипаттайды; көрініс пен күйдің арасын бөлу есте сақтауға тұрарлық бөлік. Символдық сілтеменің мақсатын өзгерту дәстүрлі клиенттер оқитынды өзгертеді, шешуші білетінді емес.

Үшінші нысан, /run/systemd/resolve/resolv.conf, әр қосылымды бір сервер тізіміне тегістейді. Сол файлға бағытталған бағдарлама сұрауларды тізімделген серверлерге тікелей жібереді және stub-ты айналып өтеді, сондықтан әр қосылым саясаты оған енді қолданылмайды. Осылайша бір машинадағы екі бағдарлама бір атқа түрлі жауап бере алады және ешқайсысы бұзылмаған.

NSS арқылы бір іздеуді қадағалаңыз

glibc атқа кім жауап беретінін шешу үшін /etc/nsswitch.conf файлын оқиды. Құрамында resolve бар hosts жолы сұрақты nss-resolve-ке бағыттайды, ол D-Bus арқылы resolved-тен сұрайды және әр қосылымның жауабын алады. Тек files dns бар жол сұрауды /etc/resolv.conf ұстаған мекенжайға жібереді.

Осы бір жол браузер мен dig арасындағы келіспеушіліктердің көбін түсіндіреді. dig resolv.conf файлын тікелей оқиды және NSS-ке ешқашан тимейді, сондықтан қосымша қолданатын жолды емес, stub-ты немесе жоғарғы серверді тексереді. getent hosts internal.example NSS арқылы өтеді, ал оның жауабын dig жауабымен салыстыру — бірінші пайдалы өлшем.

Өз шешушісін бірге алып жүретін немесе тіркелген соңғы нүктеге HTTPS арқылы DNS сөйлейтін қосымшалар екі жолды да айналып өтеді. resolv.conf ішінде де, resolved күйінде де оларды шектейтін ештеңе жоқ.

Файл кімге тиесілі және қайда сілтейтінін тексеріңіз

Бірдеңені өзгертудің алдында сілтемелер тізбегін оқыңыз, өйткені иелік қай файлдың өкілетті екенін шешеді. Төмендегі әр команда тек күйді оқиды.

stat -c '%N' /etc/resolv.conf
resolvectl status --no-pager
grep '^hosts' /etc/nsswitch.conf
ls -l /run/systemd/resolve/

Бірінші жол сілтемені және оның мақсатын бірге шығарады, ал VPN скриптіне тиесілі қарапайым файл шешушінің бұл жазбаны кіріс ретінде қабылдамайтынын білдіреді. Күй шығысы әр қосылымның серверлерін және әр сұраудың қайда кететінін анықтайтын маршруттау домендерін тізімдейді. nsswitch жолы stub-қа мүлдем жүгінетінін айтады, сондықтан файлда stub мекенжайы бар болса да онда resolve болмаса, сұраулар жергілікті тыңдаушыға жетеді, ал бөлуді ештеңе басқармайды. Соңғы тізім де маңызды, өйткені stub-resolv.conf жоқ хост мұнда сипатталған құрылымды іске қоспайды.

Егер тізбек басқа пакет басқаратын файлда аяқталса, VPN клиенті мен сол пакет келістірілуі тиіс екі ие. Сілтемені ауыстыру бір иенің жұмысын тастап, екіншісінің жұмысын орнында қалдырады.

Сілтеме иесінде түзетіңіз

VPN қосылымы өз серверлері мен домендерін өз қосылымында тіркеп, кейін ажырату кезінде қайтарып алуы керек. NetworkManager-дің resolved интеграциясы мен клиенттің өз көмекшісі екеуі де осылай жұмыс істейді; тек resolv.conf файлын қайта жазатын скрипт олай істемейді.

Бұрыннан бар қосылымда механизмді орындалу кезіндегі параметрлер көрсетеді. resolvectl dns tun0 10.40.0.53 серверді тіркейді, ал resolvectl domain tun0 '~corp.example' маршруттау доменін тіркейді. Тилда — жүк көтеретін таңба: ол сол жұрнақтың сұрауларын осы қосылыммен шектеп, қалғанын тыныш қалдырады, ал онсыз сол мән іздеу доменіне айналып, бөлу буға айналады. Бұл мекенжайлар зертханалық мысалдар, тұрақты конфигурация емес. resolvectl query host.corp.example арқылы растап, қай қосылым жауап бергенін оқыңыз.

Тіркелген серверге бәрібір маршрут керек. Сұрау дұрыс қосылымға жетіп, уақыты бітсе, ақау шешуші иелігінде емес, туннель арқылы қолжетімділікте.

Жұмыс істеп тұрған күй қандай көрінеді

Сау нәтиже үш көріністе де үйлесімді: әр қосылымның серверлері VPN бергенге сәйкес келеді, маршруттау домендері тек ішкі жұрнақтарды қамтиды, ал маңызды қосымша ішкі атты шешеді, ал жария ат әлі де жергілікті жолмен жүреді. Бір сәтті сұрау осы келісімнен кем дәлелдейді.

Содан кейін ажыратып, екі сұрауды қайталаңыз. Ажыратқаннан кейін домендерін тіркеулі қалдыратын клиент сағаттар өткен соң ішкі іздеулерде сәтсіздікке ұшырайтын машина жасайды, ашық туннельсіз және айқын себепсіз.