resolv.conf faylını redaktə etmək VPN ayrıldıqdan sonra DNS-i düzəltmir

VPN-i ayırırsınız, ping 1.1.1.1 hələ də cavab verir, amma hər ad sorğusu səhifə nəhayət əl çəkməzdən əvvəl donub qalır. Sonra cat /etc/resolv.conf yalnız tunelin içində mövcud olmuş, adətən siyahıda birinci duran bir ad serveri göstərir. Həmin sətri silmək təxminən on dəqiqəlik problemi həll etmiş kimi görünür, ta ki yuxu rejimi, Wi-Fi rouminqi və ya yenidən başlatma onu geri qaytarana qədər. Redaktə etdiyiniz fayl parametr deyil; o, başqa komponentin sahib olduğu keçid vəziyyətinin təsviridir.

Bir köhnəlmiş qeyd hər sorğuya niyə saniyələr bahasına başa gəlir

glibc resolver ad serverləri siyahısını sıra ilə gəzir və növbətini sınamazdan əvvəl timeout-un bitməsini gözləyir, resolv.conf(5) isə bu siyahını üç qeydlə məhdudlaşdırır. Tunel getdikdən sonra 10.8.0.1 kimi tunel tərəfindən resolver-i siyahının başına qoyun və hər sorğu cavab verən serverə keçməmişdən əvvəl timeout-un bahasını ödəyəcək. Simptomun DNS xətası kimi deyil, ölü bağlantı kimi görünməsinin səbəbi budur: brauzerlər bloklanır, vaxtı bitir və bəzən sonradan köhnələn keşlənmiş ünvan təqdim edir.

Bu həm də şikayətin niyə «internet xarab olub» şəklində gəldiyini izah edir. IP ünvana ping keçidin sağlam olduğunu sübut edir və bu, nasazlığı tətbiqin günahı kimi göstərir. Resolver siyahısı oxunacaq ilk və redaktə ediləcək son şeydir.

Mif: resolv.conf ayarlar faylıdır

Dəyişməzdən əvvəl yolun əslində nə olduğunu soruşun:

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

systemd-resolved işləyən hostda o, 127.0.0.53-ə işarə edən stub fayla simvolik keçiddir və əsl serverlər resolvectl-in çap etdiyi hər-keçid vəziyyətində yaşayır. NetworkManager hostunda bu, NetworkManager-in aktiv bağlantıdan yazdığı fayl ola bilər. Bəzi vendor müştərilərində bu, qoşulma zamanı yerində yenidən yazılan və bəxtiniz gətirməsə, ayrılma zamanı heç vaxt bərpa olunmayan adi fayldır. Bunlar üç fərqli sahibdir və ilk ikisini əl ilə redaktə etmək ya heç nə etmir, ya da növbəti şəbəkə hadisəsinə qədər davam edir.

resolvectl status həqiqəti deyən görünüşdür: hər-keçid DNS serverləri, marşrutlaşdırma domenləri və tunel keçidinin hələ də mövcud olub-olmaması. resolvectl query example.com daha irəli gedir və hansı interfeysin cavab verdiyini göstərir. Fayla toxunmazdan əvvəl hər ikisini istifadə edin və unutmayın ki, öz təhlükəsiz DNS-i olan brauzer bütün bunlara məhəl qoymur.

Nəyisə redaktə etməzdən əvvəl sahibini tapın

Adətən üç komponent eyni parametr üçün yarışır: systemd-resolved, NetworkManager və VPN müştərisinin quraşdırdığı hər şey. Əvvəlcə canlı olanı müəyyənləşdirin:

systemctl is-active systemd-resolved
nmcli connection show --active
ps aux | grep -E "openvpn|wg-quick|vpn"

Əgər resolved aktivdirsə və simvolik keçid onun stubuna işarə edirsə, qlobal fayl generasiya olunmuş çıxışdır və redaktəniz kosmetikdir. Əgər bağlantıya NetworkManager sahibdirsə, serverlər bağlantı profilinin ixtiyarındadır, ona görə düzəliş fayl redaktəsi deyil, nmcli xassə dəyişikliyidir. Əgər vendor demonu işləyirsə, növbəti qoşulmanı yalnız onun öz bərpa yolu keçib gəlir.

Müştərinin geridə qoyduğu keçid vəziyyətini təmizləyin

Öldürülmüş müştəri öz təmizləmə qarmağını işə sala bilməz. SIGKILL heç tutula bilmir, SIGINT və SIGTERM isə tutula bilir, ona görə məcburi öldürmədən sonra «sadəcə dayanan» tunel çox vaxt həm interfeys qeydiyyatını, həm də resolver qeydini yerində qoyur. Konkret PID-i tapın və siqnalı yalnız ona göndərin:

ps aux | grep -E "openvpn|wg-quick"
sudo kill <pid>
resolvectl revert tun0

Tam uyğunluq siyahısını oxumadan pkill -f vpn və ya killall vpn-ə əl atmayın. -f bütün əmr sətrini uyğunlaşdırır, ona görə o, sarğı skriptini, redaktor sessiyasını və ya yolunda bu sətir olan əlaqəsiz prosesi bitirə bilər. Səhv prosesi işin ortasında bitirmək resolver probleminin itirilmiş fayla çevrilmə üsuludur.

resolvectl revert həmin keçidin işləmə vaxtı DNS konfiqurasiyasını sıfırlayır, bu isə resolver-i yenidən başlatmaqdan daha dar və qlobal faylı redaktə etməkdən qat-qat dardır. Əgər tunel keçidi tamamilə yox olubsa, systemctl restart NetworkManager bağlantı vəziyyətini yenidən qurur və mənbə mövzularının təkrar-təkrar qayıtdığı addım budur. Restart=always olan xidmət menecerinə diqqət edin, çünki o, öldürülmüş müştərini və onun DNS ayarlarını düz geri qaytara bilər.

Digər istiqamət: itirilmiş, heç vaxt çatmayan DNS

Köhnəlmiş qeydin güzgü əksinə bənzəri heç bir yararlı resolver-i olmayan tuneldir. Profildəki DNS seçimi bir xahişdir; bağlantını idarə edən komponent onu resolver-ə ötürməlidir. Əgər jurnal serverin alındığını göstərir, amma tunel keçidi heç bir DNS ayarı daşımırsa, çatışmayan inteqrasiyadır, server deyil.

Ötürməni əl ilə edərək sınayın, bu «server səhvdir» ilə «heç kim tətbiq etməyib» arasında fərq qoyur:

resolvectl dns tun0 10.10.10.10
resolvectl domain tun0 ~.

Hər şeyi tutan marşrutlaşdırma domeni hər adı həmin keçidə göndərir, tam tunel müştərisinin istədiyi budur və bölünmüş DNS-in istifadə etməməli olduğu da budur. Bu ayarlar növbəti qoşulmada yox olur. Onları NetworkManager-də davamlı etmək üçün avtomatik DNS-i söndürün, serveri bağlantıya təyin edin və domeni əlavə edin:

nmcli connection modify office ipv4.ignore-auto-dns yes
nmcli connection modify office ipv4.dns 10.10.10.10
nmcli connection modify office ipv4.dns-search "~."

Yalnız daxili adlara cavab verməli olan şirkət tuneli üçün həmin zonaları hər şeyi tutan əvəzinə başında tilde ilə sadalayın ki, açıq adlar yerli resolver-dən istifadə etməyə davam etsin.

Növbəti kəsintiyə çevrilən müvəqqəti həllər

resolv.conf-u qoşulmadan əvvəl kopyalayıb sonra bərpa etmək runbook-da qanuni bir sətirdir və bu, təmir deyil, müvəqqəti həlldir. O, məhz vacib olduğu anda uğursuz olur, çünki qəza və ya məcburi yenidən başlatma bərpanı atlayır. Bunu müvəqqəti həll kimi yazın ki, növbəti şəxs onun üzərində qurmasın.

systemd-resolved-i söndürüb açıq serverləri sərt kodlaşdırmaq digər populyar addımdır. Qoşulma və ayrılmanı proqnozlaşdırıla bilən edir və hər digər şəbəkə üçün hər-keçid DNS-i aradan qaldırır, bu da daxili adlar üçün bölünmüş DNS-i pozur və sorğuları öz içində saxlamaq üçün nəzərdə tutulmuş tunelin məqsədini puça çıxarır. resolvconf quraşdırıb açıq serverləri bərkitmək əlavə bir qatla eyni qiymətə başa gəlir. Hər ikisinə diaqnostik kimi baxın: əgər o, gəzintini bərpa edirsə, öyrəndiyiniz resolver inteqrasiyasının günahkar olduğu, açıq serverlərin doğru olduğu deyil.

Davamlı düzəliş hər qat üçün bir sahibdir: tunel keçidinin DNS-inə hansı komponentin, qlobal defolta hansının sahib olduğunu qərarlaşdırın, bunu yazın və digərlərini yoldan çıxarın. Sonra ayrılmadan sonra yalnız VPN-in həll etdiyi bir adla yoxlayın. Əgər şəxsi ad hələ də cavab verirsə, qeydiyyat silinməyib; əgər heç nə həll olunmursa, fayl artıq mövcud olmayan serverə işarə edir. Hər ikisi brauzer açmazdan əvvəl resolvectl-də görünür.