Linux'тун /etc/resolv.conf үчүн атаандашкан эки кызматын токтотуңуз

DNS дайыма мурунку абалга кайтат, VPN кайра туташуусу сиздин оңдооңузду жокко чыгарат, анан командадагы бирөө файлды кулпулоону сунуштайт. Бул ырааттуулук — симптом, чечим эмес: эки компонент тең /etc/resolv.conf өзүнүкү деп ойлойт, акыркы жазган жеңет. Файлды кулпулоо менен менчик жаңжалы чечилбейт, ал жашырылат жана ошол эле учурда сиз чындап каалаган компонент бузулат. Төмөнкү төрт текшерүүнү ирети менен аткарыңыз жана тартипти файлда эмес, ага ээлик кылган деңгээлде оңдоңуз.

Текшерүү 1: бул символдук шилтемеби, жана кайда

Файлдын өзүнөн баштаңыз, анткени өзгөртүп жаткан жолуңуз такыр файл эмес болушу мүмкүн. Чечүүчүнүн аткаруу каталогуна багытталган символдук шилтеме клиенттик скрипт кайра жазган кадимки файлдан таптакыр башкача жүрөт:

ls -l /etc/resolv.conf
readlink -f /etc/resolv.conf
cat /etc/resolv.conf

systemd-resolved'дин stub жолуна шилтеме файлдын мазмуну түзүлөөрүн билдирет, ал эми кол менен өзгөртүү кийинки окуяда үстүнөн жазылат. nameserver саптары бар кадимки файлды адатта туташуу учурунда иштеген клиент же DHCP илгичи жазат. Экөө тең мыйзамдуу; маанилүүсү — бир нерсени өзгөртүүдөн мурун кайсынысы бар экенин билүү.

Текшерүү 2: кайсы демон иштеп жатат

Эмне орнотулганын эмес, эмне чындап активдүү экенин аныктаңыз. Заманбап дистрибутивде бир нече чечүүчү болушу мүмкүн, ал эми loopback интерфейсинде 53 портун кармаган жооп берет:

systemctl status systemd-resolved --no-pager
resolvectl status
ss -lunp | grep ':53'

Абалдын чыгарылышы ар бир шилтеме боюнча DNS серверлерди жана маршруттоо домендерин атайт, бул split DNS үчүн керектүү карта. Эгер ички аттар ички серверге, калганынын баары жалпыга барса, бул саясат ар бир шилтеменин домендеринде жашайт, ал эми аны файлдагы статикалык nameserver тизмесине тегиздөө бул айырманы үнсүз жоготот.

NetworkManager'дин өз конфигурациясы бул backend'дердин кайсынысын колдоноорун чечет. Негизги конфигурация файлындагы анын dns= параметри анын ички чечүүчүсү, dnsmasq, systemd-resolved жана none ортосунан тандайт, ал эми дистрибутив сиздин ордуңузга тандаган болушу мүмкүн. Бул хостто “DNS'ти оңдоо” эмнени билдирерин чечүүдөн мурун ошол параметрди окуңуз.

Текшерүү 3: VPN клиентине эмнени жазууга уруксат

Жаңжал адатта ушул жерде жашайт. Чечүүчүнүн файлын түздөн-түз кайра жазган VPN клиенти аны да кармаган ар кандай кызмат менен кармашат, ал эми жеңилүүчү — биринчи иштеген. Жакындагы OpenVPN чыгарылыштары файлды кайра жазуунун ордуна DNS жөндөөлөрүн systemd-resolved'ге бере алат, бул сиз каалаган кызматташтык жүрүм-турум; эски скрипттер жана кол менен жазылган илгичтер көбүнчө эскирген жардамчы куралды чакырат же файлды жөн гана кайра жазат.

WireGuard'дын абалы формасы боюнча окшош: интерфейстин конфигурациясы өзү DNS'ти башкарбайт, аны айланасындагы куралдар чечүүчү жардамчысы же resolved интеграциясы аркылуу жасайт. Эгер эки ушундай жардамчы орнотулган болсо, экөө тең туташуу учурунда өз дүйнө көрүнүшүн колдонууга аракет кылат.

Болжолдоонун ордуна клиенттин up жана down илгичтерин окуңуз. /etc/openvpn/up.sh же барабар каталогдогу бир нече сап shell, болбосо туш келди көрүнгөн жүрүм-турумду түшүндүрөт, жана клиентти атаандашууга эмес, кызматташууга мажбурлоочу жер да ошол.

Текшерүү 4: аны ээсинде оңдоңуз, файлда эмес

Ээсин билгенден кийин DNS'ти ошол ээ колдогон интерфейс аркылуу конфигурациялаңыз. systemd-resolved үчүн бул статикалык файлдын ордуна ар бир шилтеменин жөндөөлөрү жана маршруттоо домендери; NetworkManager үчүн туташуу профилинин DNS жөндөөлөрү жана тандалган backend; resolvconf интеграциясын колдонгон дистрибутив үчүн ошол жардамчы аркылуу жазуу.

Файлды өзгөрбөс кылбаңыз. Өзгөрбөстүк атрибуту мыйзамдуу DHCP жаңыртуулары менен VPN жаңыртууларын сиз күрөшкөндөр менен кошо токтотот жана системаны кийинки пакет жаңыртуу же кайра туташуу конфигурациядан эч ким түшүндүрө албаган бузулуу жараткан абалда калтырат. Ал менчик жаңжалын жашырат, ал эми бул дал сиз чечүүгө аракет кылган нерсе.

Эки компонент чындап катар жашоого тийиш болгон жерде аларга ар башка иштерди бериңиз. Тармак менеджерине интерфейс деңгээлиндеги конфигурацияны ээлөөгө жол бериңиз, VPN клиентине ошол эле интеграция аркылуу ар бир шилтеменин DNS'и менен домендерин кошууга мүмкүндүк бериңиз жана файлды түздөн-түз жазган үчүнчү скриптти алып салыңыз. systemd-resolved'дин документтери анын колдогон режимдерин жана ар бири /etc/resolv.conf ичинде эмнени көрсөтөрүн баяндайт. Сактоо керек болгон саясаттын көлөмүнө туура келген режимди тандаңыз. Эгер split DNS маанилүү болсо, ар бир шилтеменин домендери бар stub тартиби аны сактайт, ал эми upstream серверлерди файлга көчүргөн режим аны үнсүз тегиздейт.

Кайра туташкандан кийин текшериңиз, өзгөртүүдөн кийин эмес

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

resolvectl query build.corp.example
resolvectl query example.com
resolvectl status | head -40

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

Деплой жазууларында ээсин, backend'ди жана символдук шилтеме режимин жазып коюңуз. Ошол бир абзац келечектеги пакет жаңыртууну окуядан карап чыгуу пунктуна айландырат жана кийинки адамдын chattr буйругу менен ошол эле жаңжалды кайра ачуусуна жол бербейт.