Запрете два Linux сервиси што се натпреваруваат за /etc/resolv.conf

DNS постојано се враќа во претходната состојба, повторното поврзување на VPN ја поништува вашата поправка, и на крајот некој во тимот предлага да се заклучи датотеката. Таа секвенца е симптом, не решение: две компоненти и двете мислат дека ја поседуваат /etc/resolv.conf, и победува онаа што пишува последна. Заклучувањето на датотеката не го решава конфликтот за сопственост, само го крие и притоа ја расипува компонентата што всушност ви требаше. Извршете ги четирите проверки подолу по ред и поправете го распоредот на нивото што го поседува, а не во датотеката.

Проверка 1: дали е симболичка врска, и кон што

Започнете со самата датотека, бидејќи патеката што ја уредувате можеби воопшто не е датотека. Симболичката врска во работниот директориум на резолверот се однесува сосема поинаку од обична датотека што клиентска скрипта ја препишува:

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

Врска кон stub патека на systemd-resolved значи дека содржината на датотеката се генерира, и рачното уредување ќе биде препишано при следниот настан. Обична датотека со редови nameserver обично ја пишува оној клиент или DHCP кука што работи при поврзување. Двете се легитимни; важно е да знаете која ја имате пред да промените нешто.

Проверка 2: кој демон работи

Откријте што е навистина активно, а не што е инсталирано. На современа дистрибуција може да има неколку резолвери, а одговара оној што го држи портот 53 на loopback интерфејсот:

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 куките на клиентот наместо да претпоставувате. Неколку реда shell во /etc/openvpn/up.sh или еквивалентен директориум објаснуваат однесување што инаку изгледа случајно, и токму таму можете да го натерате клиентот да соработува наместо да се натпреварува.

Проверка 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.