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

Провера 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-у уместо да преписују датотеку, што је кооперативно понашање које желите; старије скрипте и ручно написани hook-ови често позивају застарели помоћни алат или једноставно преписују датотеку.

Ситуација са WireGuard-ом слична је по облику: сама конфигурација интерфејса не управља DNS-ом, то раде алати око ње, преко помоћника за резолвер или интеграције са resolved-ом. Ако су инсталирана два таква помоћника, оба ће при повезивању покушати да наметну своју слику света.

Читајте клијентове up и down hook-ове уместо да нагађате. Неколико редова 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.