VPN DNS marşrutlaşdırmasını hər keçid üzrə resolvectl çıxışından necə oxumalı
resolvectl status hər keçid üzrə serverləri, domenləri və defolt marşrutu göstərir. Onları birlikdə oxuyun, sonra adı sorğulayın və hansı keçidin cavab verdiyini qeyd edin.
resolvectl status əmrini işə salın və hər keçid üçün öz serverləri və öz domen sətri olan bloklar divarı ilə qarşılaşırsınız. Marşrutlaşdırmanı həll edən sətir ad serverinin ünvanı deyil, domen siyahısıdır, çünki yerli stub hər sorğunu adı iddia edən keçidə yönləndirir. Cavabı oxumazdan əvvəl bu iddiaları oxuyun, sonra adı sorğulayın və hansı keçidin onu yaratdığını yoxlayın. Düzgün keçiddən gələn səhv cavab, səhv keçiddən gələn düzgün cavabdan fərqli bir problemdir.
Hər keçid bloku sizə nə deyir
Hər blok həlledicinin həmin interfeys üçün istifadə edəcəyi serverləri, domen siyahısını və keçidin defolt marşrut olub-olmadığını sadalayır. Domen siyahısı iddialar toplusudur və həlledici ən uzun şəkilçi uyğunluğunu tətbiq edir: host.corp.example üçün sorğu corp.example daşıyan keçid tərəfindən yalnız defolt marşrutu daşıyan keçiddən əvvəl iddia edilir. Eyni şəkilçini iddia edən iki keçid nəticəni prioritet və sıralamaya buraxır, buna görə dublikatlar ilk növbədə diqqət tələb edir. Cari server sətri sadalanan serverlərdən hansının həmin anda istifadədə olduğunu göstərir.
/etc/resolv.conf daxilində 127.0.0.53 kimi stub ünvanı yalnız stubun öndə olduğunu bildirir. Cavab verən yuxarı axını adlandırmır, buna görə yalnız resolv.conf-a əsaslanan diaqnoz ilişib qalır.
Üç növ domen qeydini düzgün oxuyun
| Qeyd | Nəyi iddia edir | Adi səhv |
|---|---|---|
| corp.example | marşrutlaşdırma domeni və axtarış şəkilçisi: altındakı adlar bu keçidə gedir və sətir çılpaq adlara əlavə olunur | marşrutlaşdırma onsuz da işləyirmiş kimi göründüyü üçün silinib |
| ~corp.example | yalnız marşrut: altındakı adlar bu keçidə gedir, lakin şəkilçi əlavə olunmur | marşrutlaşdırma üçün tələb olunduğu güman edilir |
| ~. | defolt marşrut: heç bir başqa keçidin uyğun gəlmədiyi sorğuları iddia edir | bölünmüş profildə aktiv saxlanılıb, nəticədə ictimai adlar tuneldən sonra gedir |
Tilda axtarış davranışını dəyişir, marşrutlaşdırmanı yox. Tildasız qeyd həm marşrutlaşdırma domeni, həm də axtarış domenidir, ona görə altındakı adlar həmin keçidə göndərilir və tək etiketli adlara şəkilçi əlavə olunur. Tilda qeydi eyni şəkilçini marşrutlaşdırır, eyni zamanda onu axtarış siyahısından kənarda saxlayır. Buna görə tildanın silinməsi hansı çılpaq adların həll olunduğunu dəyişir və buna görə itkin tilda bölünmüş DNS nasazlığı deyil, axtarış problemidir.
Defolt marşrut qeydi başqa heç bir keçidin uyğun gəlmədiyi hər şeyi iddia edir. Tam tunel profili adətən onu istəyir, bölünmüş profil isə adətən istəmir, çünki ictimai adlar sonra özəl həllediciyə gedir və orada uğursuz ola bilər. Cədvəli profillər arasında bayraqları köçürmək əvəzinə profilin niyyətinə görə oxuyun. İki keçid eyni şəkilçini iddia etdikdə, başqa bir şeyi redaktə etməzdən əvvəl prioritet məsələsini həll edin.
Adı sorğulayın və hansı keçidin cavab verdiyini görün
query alt əmri cavabı yaradan ünvanı, protokolu və keçidi və ya əhatəni çap edir. Özəl şəkilçi ilə iddia edilməli olan bir adı və bir adi ictimai adı yoxlayın, sonra bildirilən mənbələri müqayisə edin. Özəl ad simsiz keçiddən cavab verirsə, iddia yoxdur və ya tunel işləmir; bölünmüş profildə ictimai ad tuneldən cavab verirsə, defolt marşrut çox genişdir. Bu iki nasazlıq brauzerdə eyni, bu çıxışda isə əks görünür.
resolvectl status
resolvectl query host.corp.exampleBildirilən protokolu da izləyin, çünki keşlənmiş və ya host faylından gələn cavab heç bir yuxarı axına müraciət edilmədən gələ bilər. Keşdən gələn cavab adın vaxtilə həll olunduğunu sübut edir, cari siyasətin onu düzgün marşrutlaşdırdığını yox.
Ad marşrutlaşdırmasını paket marşrutlaşdırmasından ayrı saxlayın
Həlledici qərarı yol yaratmır. Seçilmiş server hələ də öz ünvanına marşrut lazımdır və qaytarılan ünvan hələ də özəl şəbəkəyə marşrut lazımdır, buna görə düzgün DNS siyasəti heç vaxt açılmayan bağlantı ilə birgə mövcud ola bilər. Ad həll olunur və tətbiq uğursuz olursa, DNS-i yenidən dəyişmək əvəzinə ünvanı və marşrutu yoxlayın. Ad həlli və əlaqə qurulabilirliyi iki fərqli sahibi olan iki sualdır.
Tətbiqlər öz təhlükəsiz DNS parametri və ya daxili həlledici vasitəsilə sistem həlledicisini tamamilə keçə bilər. resolvectl nəticəsi sistem yolunu təsvir edir və ona məhəl qoymayan brauzer apardığınız hər testlə ziddiyyət təşkil edəcək. Siyasətin pozulduğu qənaətinə gəlməzdən əvvəl həmin parametri yoxlayın.
Adın həll olunduğu ünvanı keçidlə birlikdə qeyd edin. Səhv ünvana işarə edən düzgün ad marşrutlaşdırma deyil, qeyd problemidir.
Keçid dəyişdikdən sonra yenidən yoxlayın
Yenidən qoşulma və ya simsiz keçid keçid vəziyyətini yenidən qurur və şəbəkə meneceri əl ilə qoyulmuş hər şeyin üzərinə öz domenlərini və serverlərini yenidən quraşdıra bilər. Sonra eyni iki adı sorğulayın və qeydə alınmış baza xətti ilə müqayisə edin. Əl ilə düzəliş itibsə, düzəliş bağlantı profilində olmalıdır qabıq əmrində deyil. Əvvəl və sonranı qeyd etmək bunu görünən edir.
Yalnız hesabatın ehtiyac duyduğu adları və server kontekstini paylaşın, çünki daxili şəkilçilər topologiyanı açır. Domen marşrutlaşdırması üzrə systemd-resolved sənədləri ən uzun uyğunluq qaydasını və tilda davranışını əhatə edir və bir dəfə oxumaq yuxarıdakı cədvəl səhvlərinin çoxunun qarşısını alır: systemd-resolved sorğu marşrutlaşdırması.