Эмне үчүн 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 бергенге туура келет, маршруттоо домендери ички мүчөлөрдү гана камтыйт, ал эми маанилүү колдонмо ички атты чечет, ал эми коомдук ат дагы эле жергиликтүү жолду ээрчийт. Бир ийгиликтүү суроо бул макулдашуудан азыраак нерсени далилдейт.

Анан ажыратып, эки суроону кайталаңыз. Ажыраткандан кийин домендерин катталган бойдон калтырган кардар бир нече сааттан кийин ички издөөлөрдө ийгиликсиз болгон машина жаратат, ачык туннел жана ачык себеп жок.