Bölünmüş DNS ve VPN: alan adı kuralları IP yolları değildir
Bölünmüş DNS çözümleyiciyi ada göre seçer ve yanıtın hâlâ bir yola ihtiyacı vardır. Alan adı kuralını ve yolu ayrı ayrı, gerçekten çalıştırdığınız platformda test edin.
Dizüstü bilgisayarınız intranet.corp adresini tünel üzerinden çözerken gitlab.com sağlayıcının çözümleyicisine gitmeye devam eder ve bu, tasarlandığı gibi çalışan düzenlemedir. Bunu iki ayrı karar üretti: bir ad eşleştirme kuralı çözümleyiciyi seçti ve bir yol yanıtı geri getirdi. Herhangi birini bozun, tarayıcı dışarıdan aynı görünen bir arıza gösterir. Bölünmüş DNS hakkındaki raporların çoğu ikinci arızayı anlatırken birincisine dair kanıtlar aktarır.
İki yarı farklı yerlerde yaşar ve genellikle farklı kişilerce düzenlenir. Biri VPN profiline bağlı DNS ilkesi, diğeri tünelin kurduğu veya tuttuğu bir yoldur. Hangi yarının gerçekten hareket ettiğini kimse belirlemediğinde hata ayıklama durur.
Tek bir istekte saklı iki karar
Ad yarısı bir ilke nesnesidir, yol değildir. Windows'ta VPN profilinde bir ad çözümleme ilkesidir; Apple platformlarında DNS ayarları nesnesinde bir eşleşen alan adı kümesidir; Linux'ta bir yönlendirme alanı, bölünmüş çözümleyici satırı veya ad hizmeti anahtarının sırasıdır. Yol yarısı, tünel veya elle kurulan sıradan yönlendirmedir ve ana makine adının ne olduğunu bilmez. Bir son eki kabul eden profil yalnızca kimin yanıt vereceğine karar verir; yanıtı hiçbir zaman erişilebilir kılmaz.
Hızlı bir belirti testi ikisini ayırır: adı bir adresle değiştirin. Adres çalışıyorsa yol sağlamdır ve kural yanlıştır. Adres de başarısız olursa kural doğru olabilir ve yol eksik olabilir.
Her platform aynı ad kuralını nasıl ifade eder
Amaç aynıdır ve alan adları değildir. Bir istemciden diğerine kopyalanan örnek temiz biçimde ayrıştırılır ve asla eşleşmez. Üç biçim şöyle görünür:
| Platform | Where the rule lives | What usually breaks |
|---|---|---|
| Windows | name-resolution policy on the VPN profile | precedence against the interface suffix list |
| Apple platforms | match domains on the DNS settings object | domains attached to the wrong extension |
| Linux | routing domain, split resolver, nsswitch order | the suffix written the wrong way round |
Eşleşen veya yönlendirme alanı bir son ek testidir, bu yüzden intranet.corp git.intranet.corp adresini kapsar ve corp.intranet adresini kapsamaz; bunu tersine çevirmek tüm kurulumdaki en yaygın hatadır. Windows eşlemeyi profile bağlı bir ad çözümleme ilkesi olarak taşır ve arayüzün zaten sahip olduğu herhangi bir son ek listesine karşı kendi öncelik sırasına sahiptir. Apple platformları eşleşen alan adlarını ağ uzantısının DNS ayarları nesnesine bağlar ve sistem bunları her kapsamlı çözümleyici için uygular. Bu biçimlerin hiçbiri yol değildir ve hiçbiri erişilemeyen bir adresi erişilebilir kılamaz. Windows ad çözümleme ilkesi referansı o platformun alan adlarını ve öncelik kurallarını listeler ve bunlar Apple veya systemd belgelerinin kullandıkları değildir.
Doğru yanıt hâlâ bir yol gerektirir
Bir çözümleyici yanıtı yalnızca bir adrestir ve uygulama hâlâ oraya ulaşmak zorundadır. Bölünmüş tünel tasarımı sıklıkla 10.20.0.0/16 adresini iter ve varsayılan yolu tutar, böylece iç ad çözülür ve bağlantı sonra asılı kalır. Ters durum da aynı ölçüde yaygındır: yol vardır, ortak bir çözümleyici özel ada NXDOMAIN ile yanıt verir ve arıza yönlendirme sorunu olarak kaydedilir. Yolu önce test etmek, asla çözülmeyecek bir ad için yollara bakıp kalmanıza neden olur.
Hiçbir yarının kapsamadığı üçüncü bir kapı da vardır. Ağ geçidindeki bir ACL, bir güvenlik duvarı kuralı veya istemci tarafı ilkesi, iki karar da doğruyken bağlantıyı düşürebilir. Ad çözülüyor, yol var ve bağlantı yine zaman aşımına uğruyorsa DNS testini bırakın.
Adları ve yolları sabit bir sırayla test etme
Bir sıra seçin ve ona bağlı kalın, yoksa en son başarısız olan adımı kovalarsınız. Belgelenmiş tam iç adı çözün, yanıtın yönlendirme tablosunun taşıyabileceği bir adres olduğunu doğrulayın, sonra tünelin her şeyi yakalamadığını kanıtlamak için ortak bir adla tekrarlayın. Bir systemd ana bilgisayarında sorgu ile çözümleyicinin yönlendirme alanı bir komut uzaklıktadır:
resolvectl query intranet.corp
resolvectl domain
ip route get 10.20.5.10Bir Windows istemcisi aynı iki soruyu başka cmdlet'lerle sorar. İkincisi sistemin gerçekte kullanacağı arayüzü bildirir:
Resolve-DnsName intranet.corp -Type A
Find-NetRoute -RemoteIPAddress 10.20.5.10Arama bir adres döndürür ve yol denetimi fiziksel arayüzü adlandırırsa ad kuralı çalışmış, yol çalışmamıştır. Kısa ad başarısız olurken tam ad çözülüyorsa yanlış olan son ek listesidir, çözümleyici değil.
Karşılaştırmanın genellikle ters gittiği yer
İlk hata, ilgisiz bir ortak çözümleyiciye özel bir ad sormak ve reddi VPN hakkında kanıt olarak okumaktır. İkincisi, çalışan bir ortak aramanın tünelin çözümleyici yolunu kanıtladığını varsaymaktır. Üçüncüsü, bölünmüş tünellemeyi ve bölünmüş DNS'i tek bir tasarım kararı olarak görmektir; oysa bir kurulum birinde doğru, diğerinde bozuk olabilir. Her hata, suçlanan kısmı hiç çalıştırmamış bir testten kendinden emin sonuçlar üretir.
Kendi güvenli DNS'i olan bir tarayıcı da sistem kuralını atlayabilir, bu yüzden bir tarayıcı başarısız olurken diğerinin başarılı olması çelişki değildir. Yanıt veren çözümleyiciyi karşılaştırın, şikayet eden tarayıcıyı değil.
İki yarı da görünür olduğunda geriye kalan soru teknik değil ilke sorusudur: hangi ad alanları kuruluşa aittir, her yanıtın sahibi kimdir ve hangileri makineden tamamen ayrılmalıdır. Bunu profilin yanına yazın, çünkü kurala dokunacak bir sonraki kişinin buna ihtiyacı olacak.