Зошто 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, домените за насочување покриваат само внатрешни суфикси, а важната апликација решава внатрешно име, додека јавното име сето уште ја следи локалната патека. Едно успешно барање докажува помалку од таа согласност.

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