VPN üzerinden Azure özel DNS: resolver uç noktası mı forwarder mı
Her iki tasarım da özel bölgeleri tünel üzerinden yanıtlar. Yönetilen gelen uç noktasını bir forwarder VM ile karşılaştırın, ardından her iki durumda da bulunması gereken yolu denetleyin.
Yerinde bir sunucu, Azure VM'ine özel bir adresle ulaşır ve yine de özel ana bilgisayar adını çözemez; bu da insanları bozuk bir tünel aramaya iter. Tünel sağlam. Eksik olan bir DNS sınırıdır: yerinde tarafta hiçbir şey, belirli bir Azure özel bölgesine VNet içindeki bir resolver'ın yanıt vermesi gerektiğini bilmez. Bu boşluğu iki tasarım kapatır ve bunlar sonunda neyi işlettiğinizde farklılaşır, sorguların çalışıp çalışmamasında değil.
Tünel sorguları taşır, bölge bilgisini değil
Siteden siteye bağlantı, paketlere iki ağ arasında bir yol verir. Yerinde DNS sunucusuna hangi ad alanının Azure'a ait olduğunu veya hangi adresin yanıt vermesi gerektiğini söylemez, bu yüzden sorgu ya internete gidip boş döner ya da yerel resolver'dan hiç çıkmaz.
Düzeltmenin kolayca ayrılabilen iki yarısı vardır. Bir yarısı, tünelden gelen sorguları kabul eden VNet içindeki resolver'dır. Diğeri, yerinde tarafta tam olarak bir ad alanını o resolver'a gönderen koşullu forwarder'dır. Hiçbir yarı tek başına çalışmaz.
Bu açıklamanın geri kalanında bölgenin cloud.corp.example olduğunu varsayın ve her adresi örnek olarak görün.
Seçenek A: yönetilen gelen uç noktası
Azure DNS Private Resolver, VNet dışından gelen DNS sorgularını kabul eden bir gelen uç noktası sağlar. Bunu ayrılmış bir temsilci alt ağa dağıtır, özel bölgeyi o VNet'e bağlar ve hizmetin atadığı gelen adresi not edersiniz.
Ardından yerinde DNS sunucusunda tam ad alanı için o adrese yönelen koşullu bir forwarder oluşturursunuz:
Namespace: cloud.corp.example
Forward to: 10.20.2.4Microsoft'un karma DNS yordamı hem bölge bağlantısını hem de forwarder adımını belgeler. Yönetilen yol, yamalanacak DNS yazılımı bırakmaz ve uç nokta adresi kaynağın tüm ömrü boyunca sabit kalır.
Bedeli, artık bir resolver kaynağına, alt ağ temsilciliğine ve maliyetine sahip olmanızdır; bu, sorgu hacmi çok küçük olsa da gerçektir.
Seçenek B: VNet içinde forwarder VM
Daha eski tasarım, VNet içindeki sıradan bir VM üzerinde DNS yazılımı çalıştırır: Windows DNS, BIND veya dnsmasq; özel bölge ya yerel olarak barındırılır ya da 168.63.129.16 adresindeki Azure resolver'ına iletilir. Yerinde koşullu forwarder o VM'in özel adresini işaret eder.
Bu seçenek, hâlihazırda DNS sunucuları işleten ekipler için tanıdıktır ve günlükleme ya da split-horizon yanıtları gibi ek mantık taşıyabilir. Aynı zamanda bir DNS sunucusunun her operasyonel görevini devralır: yamalama, kullanılabilirlik için ikinci örnek, izleme ve VM değiştirildiğinde adresi değiştiğinde yeniden kurma yolu.
Sıradan bir VNet ana bilgisayarı, hizmet kurulup o istemcilere yanıt verme izni verilene kadar DNS proxy değildir ve VM kopyalarken insanların atladığı adım tam da budur.
Hangisi işletmenize uygun
Karşılaştırma hangi tasarımın daha hızlı olduğuyla ilgili değil. DNS yazılımını işletmek isteyip istemediğinizle ve sorgu hacminin uç nokta ile sorgu başına ücretlendiren yönetilen bir kaynağı haklı çıkarıp çıkarmadığıyla ilgili.
| Question | Managed inbound endpoint | Forwarder VM |
|---|---|---|
| Software to patch | None | The DNS service on every instance |
| Address stability | Fixed for the resource lifetime | Tied to the VM or its reserved address |
| Availability work | Handled by the service | Second instance, health checks, failover |
| Extra logic | Limited to resolver features | Whatever the DNS software supports |
Hangi satır karar verirse versin, yerinde forwarder kuralı aynı görünür. Her iki tasarımda da bulunması gereken kısım budur ve biri Azure içinden çözümlemenin çalıştığını ama ofisten çalışmadığını bildirdiğinde en sık eksik olan kısım da budur.
Yolu sırayla denetleyin
Bölgenin resolver'ı barındıran VNet'e bağlı olduğunu ve yerinde forwarder'ın üst etki alanını değil ad alanını adlandırdığını doğrulayın. corp.example için bir forwarder, resolver kendisi temsilcilik vermedikçe cloud.corp.example ile eşleşmez ve bu uyumsuzluk, eksik kayıt gibi görünen temiz bir olumsuz yanıt üretir.
Ardından sorgunun uç noktaya ulaştığını denetleyin: yerinde kaynağın resolver adresine bir yola ve dönüş yoluna ihtiyacı vardır; ilkenin izin verdiği yerde 53 numaralı bağlantı noktası hem UDP hem TCP için açık olmalıdır. Bir NSG eksik bölge kaydı sağlayamaz ve doğru bir bölge hiç gelmeyen bir sorguya yanıt veremez.
Teşhis ederken istenen FQDN'yi seçtiğiniz resolver'ın yanında tutun ve zaman aşımını olumsuz yanıttan ayırın. Zaman aşımı bir yol veya ilke sorunudur. Olumsuz yanıt, sorgunun geldiği ve ad alanının eşleşmediği anlamına gelir. İş sırası: bölgeyi bağlayın, koşullu forwarder'ı ekleyin, 53 numaralı bağlantı noktasını iki yönde açın, yerelden bir adı test edin ve ancak ondan sonra uygulamanın kendi yetkilendirmesine bakın.