dnsmasq'teki VPN alan adınız bir bölge aktarımı değildir

İstemcinin dnsmasq yapılandırmasında kurumsal bölgeyi ararsınız, bulamazsınız ve VPN'nin alan adını göndermediği sonucuna varırsınız. İtilen şey yönlendirme ipucudur, bölge değil. İstemci alan adını ve onun için yanıt vermesi gereken çözümleyiciyi kaydeder; yönetilen backend bunu koşullu iletmeye dönüştürür. Yanlış yere bakmak kendinden emin ve tamamen yanlış bir teşhis üretir.

İstemcinin kabul ettiği şey, ağ geçidinin sunduğu şey değildir

Bir ağ geçidi bir çözümleyici, bir alan adı ve o çözümleyiciye ulaşmak için gereken yolu sunabilir; istemci üçünü de ya da hiçbirini kabul edebilir. İçe aktarılmış bir profil, bir yardımcı betik veya itilen seçenekleri yok sayan bir politika, sunucu tarafı doğru görünürken kabul edilen kümeyi boş bırakabilir. Sunucunun yapılandırmasından değil, istemcinin kaydedilmiş durumundan başlayın, çünkü çözümleyicinin gerçekte aldığı şey o durumdur. Kabul edilen alan adı yoksa, daha ileride hiçbir şey önemli olmayacaktır. Herhangi bir önbelleği incelemeden önce bağlantının DNS özelliklerini denetleyin.

Bu ayrım, hiç gelmeyen bir alan adına ilişkin raporların çoğunu açıklar. Sunuldu ve uygulanmadı.

İki tür alan adı girdisi

Bir bağlantı sıradan arama alan adlarını ve yalnızca yönlendirme alan adlarını taşıyabilir; ikinci tür tilde ile başlar. Bir arama alan adı hem sorguları yönlendirir hem de kısa adların genişlemesini sağlar; bu bir iş istasyonunda kullanışlı, bir sunucuda ise şaşırtıcıdır. Yalnızca yönlendirme alan adı, o son ek için sorguların kısa adların nasıl çözümlendiğini değiştirmeden belirli sunuculara gitmesi gerektiğini belirtir. Aynı alan adını iki şekilde yazmak gereksizlik değildir, çünkü iki girdi farklı işler yapar.

Özel bir ad alanı için genellikle istediğiniz yalnızca yönlendirme biçimidir. Kurumsal son eki kurumsal çözümleyiciye yönelik tutar ve geri kalan her şeyi rahat bırakır.

resolv.conf'taki localhost bir hata değildir

Yerel bir önbellek çözümleyicisi kullanıldığında, sistem dosyası loopback adresine ve başka hiçbir şeye işaret etmez. Bu girdi yerel dinleyiciyi tanımlar, yöneticinin ona verdiği üst akış sunucularını değil. Kurumsal adres dosyada meşru olarak bulunmayacaktır.

Bu girdiyi genel bir çözümleyiciyle değiştirmek klasik yanlış düzeltmedir. Genel ad çözümlemesini geri getirir ve koşullu politikayı aynı düzenlemede atar.

Backend'leri karıştırmayın

Yönetilen bir dnsmasq örneği ile sistem çözümleyicisi farklı yapılandırmaya ve farklı durum görünümlerine sahip farklı programlardır. Birinin durum komutu diğeri hakkında yararlı hiçbir şey söylemez.

Yöneticinin hangi backend'i kullanacak şekilde yapılandırıldığını belirleyin, sonra o backend'in üretilen yapılandırmasını okuyun; tesadüfen var olan dağıtım geneli bir dosyayı değil. Yönetici kendi örnek yapılandırmasını yazar ve o örnek için özel seçenekleri destekler, bu yüzden ilgisiz bir genel dosyayı düzenlemek hiçbir şeyi değiştirmez ve etkisiz bir değişiklik gibi görünür. 53 numaralı bağlantı noktasında ikinci bir daemon başlatmak yararsızdan da kötüdür, çünkü artık iki program bağlantı noktasının kime ait olduğu konusunda anlaşamaz. Önce sahibi belirleyin, sonra o sahibin okuduğu yerde düzenleyin.

Ad alanını test edin, yalnızca yanıtı değil

Uygulamanın normal yolu üzerinden izin verilen bir özel adı ve bir genel kontrol adını sorgulayın. Kurumsal sunucuya doğrudan bir sorgu kaydın var olduğunu kanıtlar; istemcinin o sunucuyu seçtiğini kanıtlamaz. İkinci sorgu politikayı test eden sorgudur.

Sonra yeniden bağlanma ve bağlantı kesilmesinden sonra tekrarlayın. İlişki bağlantının yaşam döngüsünü izlemeli ve özel adlar tünel yokken çözümlenmeyi bırakmalıdır; aynı son ek için yanıt veren genel bir çözümleyiciye geri düşmek yerine. Geri düşerlerse bir sızıntı buldunuz; bu, bozuk bir aramadan farklı bir kusurdur. Hangi backend'in çalıştığını, hangi alan adlarının uygulandığını ve her sorgunun ne döndürdüğünü yazın.