Pritunl özel DNS başarısız mı? Dar bir çözümleyici yolu ekleyin
VPN havuzunu yok sayan özel bir çözümleyici daha geniş bir yol değil, kaynak istisnası gerektirir. NAT etkin bir /32 ekleyin ve gerçek bir özel aramayı test edin.
Özel adlar kurumsal ağda herkes için çözülür ve VPN’de herkes için zaman aşımına uğrar. Çözümleyici ağ geçidine yanıt verir, ona giden yol vardır ve sorgu yine de hiç yanıt alamaz. Eksik olan ne başka bir genel çözümleyici ne de daha geniş bir yoldur: özel DNS sunucusunun yanıt vermeye razı olduğu bir kaynak adresidir.
Çözümleyicinin istemci havuzunuzu reddettiğini doğrulayın
Arızanın erişilebilirlik değil kaynakla ilgili olduğunu kanıtlayarak başlayın. Bağlı bir istemciden özel çözümleyiciyi doğrudan sorgulayın ve isteğin zaman aşımına mı uğradığını yoksa ret olarak mı döndüğünü izleyin. dig @10.40.0.53 intranet.example.net +time=2 +tries=1 zaman aşımına uğraken aynı sorgunun ağ geçidinden başarılı olması, çözümleyicide bir erişim politikasına işaret eder. SERVFAIL yanıtı tamamen başka bir yeri, genellikle bölgeyi veya üst akış yönlendiricisini gösterir.
Test etmeden önce istemcinin adresini not edin. İstemcide ip -4 addr show tun0 veya konsolda gösterilen kira, çözümleyicinin hangi havuzu gördüğünü söyler.
Sonra yolun gerçekten var olduğunu doğrulayın. Çözümleyici adresini tünele gönderen yol bir ön koşuldur, çözüm değil; paketler hiç ulaşmazsa kaynak politikası hiç dikkate alınmaz. İstemcide ip route get 10.40.0.53 ile kontrol edin.
Her şeyi çevirmek yerine tek bir ana bilgisayar yolu ekleyin
Pritunl’un özel DNS kılavuzu dar çözümü anlatır: çözümleyici adresi için NAT etkin bir /32 yolu, o adres istemcilerin DNS sunucusu olarak seçilir. Yol, çözümleyicinin gördüğü kaynağı yalnızca DNS trafiği için değiştirir. Uygulama trafiği, onun için seçtiğiniz kaynağı koruyan tasarımı sürdürür.
Mevcut yolları çakışma açısından inceledikten sonra sunucunun desteklenen yol sahibi üzerinden yapılandırın. Yukarıdaki örnekte hedef NAT etkin 10.40.0.53/32 ve istemci havuzu 10.90.0.0/24 olarak kalır. Bir hizmeti düzeltmek için tüm özel aralığı çevirmeyin, çünkü istemcinin gerçek adresine dayanan her alt politika bunun yerine ağ geçidini görmeye başlar. Çözümleyicinin gerçekte aldığı adresi test araması sırasında sorgu günlüğüne bakarak doğrulayın. Tek başına bir ana bilgisayar yolu, çeviri veya izin hakkında hiçbir şey kanıtlamaz.
Çözümleyici çevrilmiş kaynağa UDP ve TCP üzerinde hâlâ izin vermeli ve yanıtları geri dönebilmelidir. Kaynağı değiştirmek eksik bir bölge veya kayıt oluşturamaz.
Sorguyu sunucunun mu yoksa istemcinin mi gönderdiğine karar verin
Pritunl ayrıca VPN Client DNS Mapping’e bağlı bir DNS vekil düzeni belgeler; burada sunucu istemciler adına üst akış sorgularını iletir. Bu modelde üst akış kaynağı sunucunun kendi ağ bağlamına aittir ve istemci tarafındaki istisna yanlış çözümdür.
Bir şey eklemeden önce hangi modelin etkin olduğunu belirleyin. Üç örtüşen onarım, bir vekil, istemcide çözümleyici değiştirme ve elle yapılan bir NAT betiği genellikle kimsenin şunu saptamadığı anlamına gelir: hangi bileşenin sorguyu göndermesi gerektiğini. bootstrap’i de kontrol edin: yalnızca özel bir çözümleyici, tünel var olmadan uç noktayı bulmanın tek yolu olamaz ve kalıcı bir çözümleyici değişikliği bağlantıdan uzun yaşamamalıdır.
Genel bir web sayfasını değil, özel bir aramayı test edin
Değişikliği uygulayıp yeniden bağlandıktan sonra istemcinin etkin çözümleyici yapılandırmasını inceleyin, ardından yalnızca özel bölgede var olduğunu bildiğiniz bir adı çözün. Açık bir sunucu olmadan dig intranet.example.net istemcinin gerçekte ne kullandığını gösterir. Ardından o aramanın döndürdüğü adrese bir istek gönderin, çünkü çözümleme ve hizmete erişim ayrı adımlardır. Genel siteleri DNS-over-HTTPS üzerinden yükleyen bir tarayıcı, işletim sisteminin özel çözümleyici yolunu kanıtlamaz. Genel bir ikincil çözümleyici de iç bölge için yetkili değildir.
Çözümleyici adresini, /32 yolunu ve istemcinin DNS ayarını birlikte sunucu notlarına kaydedin. Bu yapılandırmanın yalnızca yarısını geri yüklemek özgün arızayı yeniden üretir.
Son olarak, DNS başarılı olduktan sonra tünelin uygulama hedefine hâlâ yönlendirme yaptığını doğrulayın. Yol, hizmete erişim ve kimlik doğrulama ad çözümlemesinden bağımsız kalır ve çalışan bir arama aktarım hızı hakkında hiçbir şey söylemez. Özel sayfa yavaş ama çözülüyorsa çözümleyici işini yapmıştır ve sorun yola taşınmıştır.