VPN DNS yönlendirmesini resolvectl çıktısından bağlantı bazında okuma
resolvectl status her bağlantı için sunucuları, alan adlarını ve varsayılan yolu gösterir. Bunları birlikte okuyun, sonra adı sorgulayın ve hangi bağlantının yanıtladığını not edin.
resolvectl status komutunu çalıştırın ve her bağlantı için bir blok duvarı elde edersiniz; her bloğun kendi sunucuları ve kendi alan adı satırı vardır. Yönlendirmeyi belirleyen satır, ad sunucusunun adresi değil alan adı listesidir, çünkü yerel stub her sorguyu adı talep eden bağlantıya iletir. Yanıtı okumadan önce bu talepleri okuyun, sonra adı sorgulayın ve hangi bağlantının onu ürettiğini kontrol edin. Doğru bağlantıdan gelen yanlış yanıt, yanlış bağlantıdan gelen doğru yanıttan farklı bir sorundur.
Her bağlantı bloğunun size söylediği
Her blok, çözümleyicinin o arayüz için kullanacağı sunucuları, alan adı listesini ve bağlantının varsayılan yol olup olmadığını listeler. Alan adı listesi bir talep kümesidir ve çözümleyici en uzun sonek eşleşmesini uygular: host.corp.example için sorgu, yalnızca varsayılan yolu taşıyan bağlantıdan önce corp.example taşıyan bağlantı tarafından talep edilir. Aynı soneki talep eden iki bağlantı sonucu öncelik ve sıralamaya bırakır, bu yüzden kopyalar önce dikkat çeker. Geçerli sunucu satırı, listelenen sunuculardan hangisinin o anda kullanımda olduğunu gösterir.
/etc/resolv.conf içindeki 127.0.0.53 gibi bir stub adresi yalnızca stub'un önde olduğunu söyler. Yanıt veren üst kaynağı adlandırmaz, bu yüzden yalnızca resolv.conf'a dayanan bir teşhis tıkanır.
Üç tür alan adı kaydını doğru okuyun
| Kayıt | Neyi talep eder | Yaygın hata |
|---|---|---|
| corp.example | yönlendirme alanı ve arama soneki: altındaki adlar bu bağlantıya gider ve dize çıplak adlara eklenir | yönlendirme zaten çalışıyor gibi göründüğü için kaldırıldı |
| ~corp.example | yalnızca yol: altındaki adlar bu bağlantıya gider, ancak sonek eklenmez | yönlendirme için gerekli olduğu varsayıldı |
| ~. | varsayılan yol: hiçbir başka bağlantının kapsamadığı sorguları talep eder | bölünmüş profilde etkin bırakıldı, bu yüzden genel adlar tüneli izler |
Tilde arama davranışını değiştirir, yönlendirmeyi değil. Tildesiz kayıt hem yönlendirme alanı hem arama alanıdır, bu yüzden altındaki adlar o bağlantıya gönderilir ve tek etiketli adlara sonek eklenir. Tildeli kayıt aynı soneki yönlendirir ama arama listesinin dışında tutar. Bu yüzden tildeyi kaldırmak hangi çıplak adların çözüldüğünü değiştirir ve bu yüzden eksik tilde bölünmüş DNS arızası değil arama sorunudur.
Varsayılan yol kaydı, hiçbir başka bağlantının kapsamadığı her şeyi talep eder. Tam tünel profili genellikle onu ister, bölünmüş profil genellikle istemez, çünkü genel adlar o zaman özel çözümleyiciye gider ve orada başarısız olabilir. Bayrakları profiller arasında kopyalamak yerine tabloyu profilin amacına göre okuyun. İki bağlantı aynı soneki talep ettiğinde, başka bir şeyi düzenlemeden önce öncelik sorununu çözün.
Bir adı sorgulayın ve hangi bağlantının yanıtladığını görün
query alt komutu adresi, protokolü ve yanıtı üreten bağlantıyı veya kapsamı yazdırır. Özel sonekin talep etmesi gereken bir adı ve sıradan bir genel adı test edin, sonra bildirilen kaynakları karşılaştırın. Özel ad kablosuz bağlantıdan yanıtlıyorsa talep eksik ya da tünel kapalıdır; bölünmüş profilde genel bir ad tünelden yanıtlıyorsa varsayılan yol çok geniştir. Bu iki arıza tarayıcıda aynı, bu çıktıda ise ters görünür.
resolvectl status
resolvectl query host.corp.example
Bildirilen protokole de dikkat edin, çünkü önbellekten veya hosts dosyasından gelen bir yanıt hiçbir üst kaynağa sorulmadan gelebilir. Önbellekten gelen yanıt, adın bir zamanlar çözüldüğünü kanıtlar, mevcut ilkenin onu doğru yönlendirdiğini değil.
Ad yönlendirmesini paket yönlendirmesinden ayrı tutun
Çözümleyici kararı bir yol oluşturmaz. Seçilen sunucu hâlâ kendi adresine bir yol ister ve döndürülen adres hâlâ özel ağa bir yol ister, bu yüzden doğru bir DNS ilkesi hiç açılmayan bir bağlantıyla birlikte var olabilir. Bir ad çözülüp uygulama başarısız olduğunda, DNS'i yeniden değiştirmek yerine adresi ve yolu inceleyin. Ad çözümleme ve erişilebilirlik, iki farklı sahibi olan iki sorudur.
Uygulamalar, kendi güvenli DNS ayarları veya paketlenmiş bir çözümleyici aracılığıyla sistem çözümleyicisini tamamen atlayabilir. resolvectl sonucu sistem yolunu tanımlar ve onu yok sayan bir tarayıcı yaptığınız her testle çelişir. İlkenin bozuk olduğu sonucuna varmadan önce o ayarı kontrol edin.
Adın çözüldüğü adresi bağlantının yanına not edin. Yanlış adrese işaret eden doğru bir ad, yönlendirme değil kayıt sorunudur.
Bağlantı değiştikten sonra yeniden kontrol edin
Yeniden bağlanma veya kablosuz ağ değişimi bağlantı durumunu yeniden kurar ve ağ yöneticisi kendi alan adlarını ve sunucularını elle ayarlanan her şeyin üzerine yeniden kurabilir. Ardından aynı iki adı sorgulayın ve kaydedilen temel çizgiyle karşılaştırın. Elle yapılan bir düzenleme kaybolduysa, düzeltme bağlantı profilinde olmalıdır ve bir shell komutunda değil. Öncesini ve sonrasını kaydetmek bunu görünür kılan şeydir.
Yalnızca raporun ihtiyaç duyduğu adları ve sunucu bağlamını paylaşın, çünkü iç sonekler topolojiyi açığa çıkarır. systemd-resolved belgeleri alan adı yönlendirmesinde en uzun eşleşme kuralını ve tilde davranışını kapsar; bir kez okumak yukarıdaki tablo hatalarının çoğunu önler: systemd-resolved içinde sorgu yönlendirme.