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 командасымен сол қақтығысты қайта ашуына жол бермейді.