Her bölünmüş DNS isteği aynı cümleyle başlar: şirket adları şirket DNS'ine gider, geri kalan her şey çalışmaya devam eder. Bu cümleyi bir yapılandırmaya dönüştürmek, her işletim sistemi için üç soruyu yanıtlamak demektir ve yanıtlar her birinde farklı mekanizmalar kullanır. Bir Linux dizüstünde çalışan profiller Windows'ta çoğu zaman tünelle hiçbir ilgisi olmayan nedenlerle başarısız olur. Boşluk genellikle yol ile karıştırılan bir çözümleyici ayarı.

Önce ilkeyi adlandırın, sonra onu ifade eden platform ilkelini seçin.

Karıştırması kolay üç ayar

Arama soneki kısa bir adı genişletir: files yazdığınızda, çözümleyici sonekleri sırayla denediğinde files.corp.example olur. Bir yönlendirme alan adı, bir ad alanı içindeki sorguları hangi çözümleyicinin yanıtlayacağını seçer. Bir IP yolu yalnızca seçilen çözümleyiciyi erişilebilir kılar. Bu üçü farklı katmanlarda yaşar ve birini diğerinin yerine koymak doğru görünen ama hiçbir şeyi çözmeyen bir yapılandırma üretir.

Karışıklığın bir bedeli var: arama soneki eklemek her kısa adı iş çözümleyicisine gönderir, başka yere ait adlar dahil. Bir yönlendirme alan adı seçmek, ilgisiz sorguları yerel çözümleyicide tutarken *.corp.example adresini tünelden geçirmeye devam eder.

Linux: yalnızca yönlendirme alan adı, arama soneki değil

systemd-resolved üzerinde tilde ile başlayan bir alan adı yalnızca yönlendirme alan adıdır; bu, o ad alanına ait sorguların bağlı çözümleyiciye gittiği ve aynı zamanda arama soneki haline gelmediği anlamına gelir. resolvectl domain tun0 '~corp.example' bunu ayarlar ve resolvectl dns tun0 10.8.0.1 sunucuyu adlandırır. Her iki ayar da arayüze aittir, dolayısıyla onunla birlikte kaybolur. İnsanların atladığı kısım tildir ve o olmadan kısa adlar iş çözümleyicisi üzerinden çözülmeye başlar.

Aynı alan adını genel bir arama soneki olarak da kurmayın. Bu iki ayar gereksiz değildir; biri yönlendirir, diğeri yazdığınızı yeniden yazar.

Windows ad alanı ilkesi ister, sonek değil

Windows bölünmüş DNS ilkesini bağdaştırıcının DNS sonekinde değil, ad çözümleme ilkesi tablosunda tutar. Bir kural, bir ad alanını belirli sunucularla eşler: Add-DnsClientNrptRule -Namespace .corp.example -NameServers 10.8.0.1. Yalnızca soneki ayarlamak kısa adların nasıl göründüğünü değiştirir; sorguyu başka bir sunucuya yönlendirmez.

Bağlandıktan sonra Get-DnsClientNrptPolicy ile geçerli ilkeyi denetleyin, çünkü önceki bir bağlantıdan kalan kural tünelden daha uzun yaşayabilir. Tünel düştüğünde kuralları adlarıyla kaldırın ve temizliğin doğru girdiyi hedeflemesi için görünen adı sabit tutun.

Platform başına tek bir çözümleyici sahibi tutun

Bir masaüstü yöneticisi, bir OpenVPN up betiği ve yerel bir çözümleyici arka plan programı aynı yapılandırmayı yazmaya çalışabilir. Anlaşamadıklarında son yazan kazanır ve sonuç kaldırma sırasına bağlıdır. Çözümleyici durumuna sahip olacak tek bir bileşen seçin, diğerlerinin yazmak yerine raporlamasına izin verin ve yeniden bağlanmayı test edin: ilke, kuralları çoğaltmadan bunu atlatmalıdır. Bağlantı kesilmeyi de test edin, çünkü kalan durum sonraki bağlantının farklı davranmasına yol açar.

Kendi şifreli çözümleyicisiyle gelen uygulamalar işletim sisteminin ilkesini tamamen yok sayar. Bu, uygulamanın bir özelliğidir, tünelin kusuru değil.

Sonucu doğrulayın, profil metnini değil

Her platformda tünelden geçmesi gereken bir adı ve geçmemesi gereken bir adı çözün ve hangi sunucunun yanıtladığını doğrulayın. resolvectl query host.corp.example ve Resolve-DnsName host.corp.example ikisi de yanıt veren sunucuyu bildirir. Yeniden bağlandıktan sonra tekrarlayın. Ardından tünelin çözümleyicisine profilin ilettiği adreste erişilebildiğini doğrulayın, çünkü erişilemeyen bir sunucuyu gösteren doğru bir ilke de hiç ilke yokmuş gibi başarısız olur.

Amaçlanan davranışı profilin notlarına kaydedin: hangi sonek yönlendirir, hangi sunucu onu yanıtlar ve geri kalan her şeye ne olur. Destekleyeceğiniz sonraki platform, yapılandırma dosyasından çok o cümleye ihtiyaç duyacak.

İlgili makaleler