Зашто resolv.conf приказује DNS вашег VPN-а, а упити га игноришу

У дневницима ништа не изгледа погрешно: интерфејс је активан, резолвер пријављује DNS сервер VPN-а, а датотека на диску га наводи. Ипак, интерно име хоста се и даље разрешава преко локалног рутера. Ове три тврдње нису противречне, јер су датотека, стање по свакој вези и путања упита различити објекти који случајно деле исто име. Следи путања коју упит заиста прелази на хосту са 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 да одлучи ко одговара на име. Линија hosts која садржи resolve усмерава питање на nss-resolve, који пита resolved преко D-Bus-а и добија одговор по вези. Линија само са files dns шаље упит на адресу коју држи /etc/resolv.conf.

Та једна линија објашњава већину неслагања између прегледача и dig. dig чита resolv.conf директно и никад не дира NSS, па тестира stub или надређени сервер, а не путању коју апликација користи. getent hosts internal.example пролази кроз NSS, а поређење његовог одговора са одговором dig је прво корисно мерење.

Апликације које носе сопствени резолвер или говоре DNS преко HTTPS-а са фиксном крајњом тачком заобилазе обе путање. Ништа у 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 веза треба да региструје своје сервере и своје домене на сопственој вези, а затим да их повуче при искључивању. Интеграција resolved-а у NetworkManager-у и сопствени помоћник клијента раде управо тако; скрипта која само преписује resolv.conf не ради то.

На вези која већ постоји, механизам показују подешавања у току извршавања. resolvectl dns tun0 10.40.0.53 прикључује сервер, а resolvectl domain tun0 '~corp.example' прикључује домен рутирања. Тилда је носећи знак: ограничава упите за тај суфикс на ову везу и оставља све остало на миру, док иста вредност без ње постаје домен претраге и подела испари. Те адресе су лабораторијски примери, а не трајна конфигурација. Потврдите са resolvectl query host.corp.example и прочитајте која је веза одговорила.

Регистровани сервер ипак треба руту. Када упит стигне до праве везе и истекне, квар је у доступности кроз тунел, а не у власништву резолвера.

Како изгледа радно стање

Здрав резултат је доследан у сва три приказа: сервери по свакој вези се поклапају са оним што је VPN доделио, домени рутирања покривају само интерне суфиксе, а важна апликација разрешава интерно име док јавно име и даље следи локалну путању. Један успешан упит доказује мање од те усклађености.

Затим се искључите и поновите оба упита. Клијент који после расклапања остави своје домене регистроване ствара машину која сатима касније не успева у интерним претрагама, без отвореног тунела и без очигледног узрока.