Göndərilən DNS serveri jurnalda görünür, tunel açıqdır, daxili adlar isə yenə də uğursuz olur. Göndərmənin özündə heç nə pozulmayıb; parametr çatıb və orada dayanıb. Göndərilən DNS seçimi müştəriyə bir mesajdır, əməliyyat sisteminin həlledicisinə göstəriş deyil, və bu ikisi arasındakı ötürmə bu halların çoxunun bitdiyi yerdir. Beş yoxlama, ardıcıllıqla, baş verməyən ötürməni tapır.

Birinci yoxlama: bağlantı necə başlayır

Bağlantının sahibi həlledici parametrlərini kimin tətbiq edə biləcəyini müəyyən edir. Qabıqdan verilən birbaşa openvpn əmri yalnız öz prosesinə sahibdir, systemd uniti, NetworkManager və ya satıcı müştərisi isə DNS-i yayımlamağın öz yoluna malikdir. Onlardan hər hansı birini güman etməzdən əvvəl proses siyahısını və unit adını oxuyun.

Komanda sətri prosesi avtomatik olaraq NetworkManager bağlantısı deyil, NetworkManager bağlantısı da avtomatik olaraq resolv.conf-u yazan şey deyil. Bu iki fərziyyə bu araşdırmada itirilən saatların çoxunu izah edir. Gördüyünüz interfeys üçün DNS-i hansı komponentin yayımlayacağını soruşun.

Davam etməzdən əvvəl sahibi yazın. Sonrakı hər yoxlama ondan asılıdır.

İkinci yoxlama: həlledici bağlantısı əslində nə saxlayır

systemd-resolved hostunda resolvectl status hər bağlantını DNS serverləri və domenləri ilə siyahıya alır. Tunel bağlantısını tapın və qeydlərini oxuyun, interfeysin tun0 adlandığını güman etməyin, çünki nömrələmə yaradılma sırasına uyğundur. Göndərilən ünvan bağlantıda yoxdursa, sorğu deyil, ötürmə uğursuz olub.

Ünvan varsa, növbəti sual budur: həmin bağlantı hansı domenləri iddia edir. Domen siyahısı olmayan bağlantı yalnız birbaşa soruşulan adlara cavab verir, bu isə split-DNS qurulumunun istədiyi şey deyil. Ünvan təkbaşına zəruridir, amma kifayət deyil.

Hər hansı nəticə çıxarmazdan əvvəl həlledici çıxışındakı bağlantı adını VPN jurnalındakı interfeys adı ilə müqayisə edin. Orada uyğunsuzluq adətən jurnal sətrinin başqa prosesdən gəldiyini bildirir.

Üçüncü yoxlama: adlar fəzası həmin bağlantını seçirmi

Həlledici düzgün serveri saxlaya və yenə də sorğulanmaya bilər. Hər bağlantı üzrə domen hansı sorğunun hansı bağlantıya getdiyini müəyyən edir, marşrutlaşdırma domeni olmadan isə xüsusi adlar fəzası defolt bağlantının dediyinə qayıdır. Buna görə daxili ad üçün resolvectl query uğurlu ola bilər, tətbiq isə yenə də uğursuz olur. Tətbiq tamamilə başqa həlledici yolu istifadə edə bilər.

Domen təyinatını yoxlayın, təkcə server ünvanını deyil. ~corp.example kimi yazılmış domen marşrutlaşdırma domenidir və tilde adın uyğunlaşdırılma üsulunu dəyişir.

Tətbiqin öz həlledicisi varsa, sistem aləti ilə deyil, onun istifadə etdiyi mexanizmlə sınaqdan keçirin. Sistem həlledicisini yan keçən sorğu aləti bağlantı vəziyyətindən asılı olmayaraq uğurlu olacaq.

Dördüncü yoxlama: iki yox, bir sahib

NetworkManager artıq VPN-i və həlledici vəziyyətini idarə edirsə, əlaqəsiz bir qarmaq skripti əlavə etmək rəqabət edən yazıcılar yaradır. Paketin təqdim etdiyi systemd-resolved qarmağı dəstəklənən inteqrasiyadır və müəyyən həyat dövrü gözləyir: script-security 2, up yolu, up-restart, down yolu və down-pre. Bu seçimlər qeydiyyatın və silinmənin yalnız ilk bağlantıda deyil, düzgün anlarda baş verməsini təmin edir.

Bələdçidən kopyalanmış nümunə yerinə paketdən quraşdırılmış yoldan istifadə edin. İcazələr də vacibdir, çünki qarmaq imtiyazlar endirildikdən sonra işləyir.

Paylama həlledici skriptini çıxış hədəfini dəyişmək üçün redaktə etmək bir hostun keçici həllini qeyd edir. Bu ümumi təmir deyil.

Beşinci yoxlama: yenidən qoşulmadan sonra eyni nəticə

Yenidən qoşulun və bağlantını yenidən oxuyun. Bir dəfə görünüb növbəti keçiddə yox olan qeydiyyat bu bütün yoxlama siyahısının tutmaq üçün mövcud olduğu nasazlıqdır. Yuxudan sonra, məcburi yenidən qoşulmadan sonra və həlledici xidmətinin yenidən başladılmasından sonra sınaqdan keçirin. Hər keçid fərqli sıralama fərziyyəsini yoxlayır.

Yalnız yenidən qoşulmada bütün beş yoxlama keçəndə göndərilən parametrlərin istifadədə olduğunu deyə bilərsiniz. Bundan əvvəlki hər şey uğurlu bir anın anlıq görüntüsüdür.

Əlaqəli məqalələr