İki Linux xidmətinin /etc/resolv.conf üstündə rəqabətini dayandırın

DNS daim geri qayıdır, VPN yenidən qoşulması düzəlişinizi ləğv edir və komandada kimsə nəticədə faylı kilidləməyi təklif edir. Bu ardıcıllıq simptomdur, həll deyil: iki komponent hər ikisi /etc/resolv.conf faylına sahib olduğuna inanır və son yazan qalib gəlir. Faylı kilidləmək sahiblik konfliktini həll etmir, sadəcə onu gizlədir və eyni zamanda əslində istədiyiniz komponenti pozur. Aşağıdakı dörd yoxlamanı sıra ilə edin və düzəlişi faylda deyil, ona sahib olan səviyyədə edin.

Yoxlama 1: bu simvolik keçiddirmi və hara

Faylın özü ilə başlayın, çünki redaktə etdiyiniz yol ümumiyyətlə fayl olmaya bilər. Həlledici proqramın işləmə qovluğuna verilən simvolik keçid, müştəri skriptinin yenidən yazdığı adi fayldan tamamilə fərqli davranır:

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

systemd-resolved stub yoluna keçid faylın məzmununun yaradıldığını bildirir və əl ilə redaktə növbəti hadisədə üzərinə yazılacaq. nameserver sətirləri olan adi fayl adətən qoşulma zamanı işləyən hansısa müştəri və ya DHCP qarmağı tərəfindən yazılır. Hər ikisi qanunidir; vacib olan heç nəyi dəyişməzdən əvvəl hansına sahib olduğunuzu bilməkdir.

Yoxlama 2: hansı daemon işləyir

Qurulanı deyil, həqiqətən aktiv olanı öyrənin. Müasir bir distributivdə bir neçə həlledici ola bilər və loopback interfeysində 53 portunu tutan cavab verəndir:

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

Status çıxışı hər keçid üzrə DNS serverlərini və marşrutlaşdırma domenlərini göstərir; bu, split DNS üçün lazım olan xəritədir. Daxili adlar daxili serverə, qalan hər şey açıq serverə getməlidirsə, bu siyasət hər keçid üzrə domenlərdə yaşayır və onu fayldakı statik nameserver siyahısına düzləşdirmək fərqi səssizcə itirir.

NetworkManager-in öz konfiqurasiyası bu backendlərdən hansını istifadə etdiyini müəyyən edir. Əsas konfiqurasiya faylındakı dns= parametri onun daxili həlledicisi, dnsmasq, systemd-resolved və none arasında seçim edir və distributiv sizin yerinizə seçmiş ola bilər. Bu hostda “DNS-in düzəldilməsi”nin nə demək olduğuna qərar verməzdən əvvəl həmin parametri oxuyun.

Yoxlama 3: VPN müştərisinə nə yazmağa icazə verilir

Konflikt adətən burada yaşayır. Həlledici faylını birbaşa yenidən yazan VPN müştərisi onu da saxlayan istənilən xidmətlə dava edəcək və uduzan ilk işləyəndir. Yeni OpenVPN buraxılışları faylı yenidən yazmaq əvəzinə DNS parametrlərini systemd-resolved-a verə bilər; bu, istədiyiniz kooperativ davranışdır; köhnə skriptlər və əl ilə yazılmış qarmaqlar tez-tez köhnə köməkçi proqramı çağırır və ya sadəcə faylın üzərinə yazır.

WireGuard-ın vəziyyəti forma baxımından oxşardır: interfeys konfiqurasiyası özü DNS-i idarə etmir, ətrafındakı alətlər isə həlledici köməkçisi və ya resolved inteqrasiyası vasitəsilə idarə edir. İki belə köməkçi quraşdırılıbsa, hər ikisi qoşulma zamanı dünyaya öz baxışını tətbiq etməyə çalışacaq.

Təxmin etmək əvəzinə müştərinin qoşulma və ayrılma qarmaqlarını oxuyun. /etc/openvpn/up.sh faylındakı və ya bənzər qovluqdakı bir neçə sətir shell əmri, əks halda təsadüfi görünən davranışı izah edir və müştərini rəqabət etmək əvəzinə əməkdaşlığa məcbur etmək üçün yer də elə oradır.

Yoxlama 4: düzəlişi faylda deyil, sahibində edin

Sahibini bildikdən sonra DNS-i həmin sahibin dəstəklədiyi interfeys vasitəsilə konfiqurasiya edin. systemd-resolved üçün bu, statik fayl əvəzinə hər keçid üzrə parametrlər və marşrutlaşdırma domenləri deməkdir; NetworkManager üçün bu, bağlantı profilinin DNS parametrləri və seçilmiş backend deməkdir; resolvconf inteqrasiyası istifadə edən distributiv üçün bu, həmin köməkçi vasitəsilə yazmaq deməkdir.

Faylı dəyişməz etməyin. Dəyişməzlik atributu qanuni DHCP yenilənmələrini və VPN yeniləmələrini də sizinlə dava edənlərlə birlikdə dayandırır və sistemi növbəti paket yeniləməsinin və ya yenidən qoşulmanın konfiqurasiyadan heç kimin izah edə bilmədiyi uğursuzluq yaratdığı vəziyyətdə qoyur. O, sahiblik konfliktini gizlədir; bu isə həll etməyə çalışdığınız şeydir.

İki komponent həqiqətən birgə mövcud olmalıdırsa, onlara fərqli işlər verin. Şəbəkə menecerinə interfeys səviyyəli konfiqurasiyanın sahibi olmağa icazə verin, VPN müştərisinin eyni inteqrasiya vasitəsilə hər keçid üzrə DNS və domenlər töhfə verməsinə icazə verin və faylı birbaşa yazan üçüncü skripti silin. systemd-resolved sənədləri onun dəstəklədiyi rejimləri və hər birinin /etc/resolv.conf faylında nə göstərdiyini izah edir. Saxlamağınız lazım olan siyasətin həcminə uyğun rejimi seçin. Split DNS vacibdirsə, hər keçid üzrə domenlərlə stub quruluşu onu qoruyur, yuxarı axın serverlərini fayla kopyalayan rejim isə onu səssizcə düzləşdirir.

Redaktədən sonra deyil, yenidən qoşulmadan sonra yoxlayın

Dəyişikliyinizdən dərhal sonra düzgün görünən fayl heç nəyi sübut etmir, çünki növbəti hadisə hələ baş verməyib. Onu əvvəllər pozan ardıcıllığı işə salın: tuneli aşağı salıb qaldırın, DHCP lizinqini yeniləyin və ya interfeysi dəyişdirin, sonra eyni dəyərləri yenidən oxuyun.

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

Sonra vacib fərqi təsdiqləyin: daxili ad daxili server vasitəsilə həll olunur, açıq ad isə hələ də işləyir. Hər şeyi daxili serverə göndərən konfiqurasiya kimsə tunel vasitəsilə internetə çıxmağa çalışana qədər yaxşı görünür, hər şeyi açıq serverə göndərən konfiqurasiya isə daxili adları sızdırır.

Sahibi, backend-i və simvolik keçid rejimini yerləşdirmə qeydlərində qeyd edin. Həmin bir abzas gələcək paket yeniləməsini hadisədən yoxlama bəndinə çevirir və növbəti şəxsin eyni konflikti chattr əmri ilə yenidən kəşf etməsinin qarşısını alır.