DNS peribadi Azure melalui VPN: titik akhir resolver atau forwarder

Pelayan di premis mencapai VM Azure melalui alamat peribadi dan masih tidak dapat menyelesaikan nama hos peribadinya, yang membuat orang mencari terowong yang rosak. Terowong itu baik. Yang hilang ialah sempadan DNS: tiada apa di sisi premis yang tahu bahawa zon peribadi Azure tertentu harus dijawab oleh resolver di dalam VNet. Dua reka bentuk menutup jurang itu, dan kedua-duanya berbeza dari segi apa yang akhirnya anda kendalikan, bukan dari segi sama ada pertanyaan berfungsi.

Terowong membawa pertanyaan, bukan pengetahuan zon

Sambungan tapak-ke-tapak memberi paket laluan antara dua rangkaian. Ia tidak memberitahu pelayan DNS premis ruang nama mana milik Azure atau alamat mana yang harus menjawab, jadi pertanyaan sama ada pergi ke internet dan kembali kosong, atau tidak pernah meninggalkan resolver tempatan.

Pembaikan mempunyai dua bahagian yang mudah dipisahkan. Satu bahagian ialah resolver di dalam VNet yang menerima pertanyaan yang datang melalui terowong. Yang lain ialah forwarder bersyarat di sisi premis yang menghantar tepat satu ruang nama kepada resolver itu. Tiada bahagian berfungsi sendirian.

Anggap zon itu ialah cloud.corp.example untuk baki penerangan ini, dan anggap setiap alamat sebagai ilustrasi.

Pilihan A: titik akhir masuk terurus

Azure DNS Private Resolver menyediakan titik akhir masuk yang menerima pertanyaan DNS dari luar VNet. Anda menggunakan ia dalam subnet diwakilkan khusus, memautkan zon peribadi ke VNet itu, dan mencatat alamat masuk yang diberikan oleh perkhidmatan itu.

Pada pelayan DNS premis anda kemudian mencipta forwarder bersyarat untuk ruang nama tepat ke arah alamat itu:

Namespace: cloud.corp.example
Forward to: 10.20.2.4

Prosedur DNS hibrid Microsoft mendokumenkan kedua-dua pautan zon dan langkah forwarder. Laluan terurus tidak meninggalkan perisian DNS untuk ditampal, dan alamat titik akhir kekal stabil sepanjang hayat sumber itu.

Harganya ialah anda kini memiliki sumber resolver, delegasi subnetnya dan kosnya, yang nyata walaupun jumlah pertanyaan sangat kecil.

Pilihan B: VM forwarder di dalam VNet

Reka bentuk lama menjalankan perisian DNS pada VM biasa di dalam VNet: Windows DNS, BIND atau dnsmasq, dengan zon peribadi sama ada dihoskan secara tempatan atau dimajukan ke resolver Azure di 168.63.129.16. Forwarder bersyarat premis menunjuk ke alamat peribadi VM itu.

Pilihan ini biasa bagi pasukan yang sudah mengendalikan pelayan DNS, dan ia boleh membawa logik tambahan seperti pengelogan atau jawapan split-horizon. Ia juga mewarisi setiap tugas operasi pelayan DNS: tampalan, contoh kedua untuk ketersediaan, pemantauan dan laluan pembinaan semula apabila VM diganti dan alamatnya berubah.

Hos VNet biasa bukan proksi DNS sehingga perkhidmatan dipasang dan dibenarkan menjawab klien tersebut, dan itulah langkah yang orang tertinggal apabila mengklon VM.

Mana yang sesuai dengan operasi anda

Perbandingan bukan tentang reka bentuk mana yang lebih pantas. Ia tentang sama ada anda mahu mengendalikan perisian DNS sama sekali, dan sama ada jumlah pertanyaan mewajarkan sumber terurus yang mengebil mengikut titik akhir dan mengikut pertanyaan.

Baris mana pun yang menentukan, peraturan forwarder di premis kelihatan sama. Itulah bahagian yang mesti ada dalam kedua-dua reka bentuk, dan itulah bahagian yang paling kerap hilang apabila seseorang melaporkan bahawa penyelesaian berfungsi dari dalam Azure tetapi tidak dari pejabat.

Semak laluan mengikut urutan

Sahkan zon dipautkan ke VNet yang menyimpan resolver, dan forwarder premis menamakan ruang nama dan bukan domain induk. Forwarder untuk corp.example tidak akan sepadan dengan cloud.corp.example melainkan resolver itu sendiri mewakilkan, dan ketidakpadanan itu menghasilkan jawapan negatif bersih yang kelihatan seperti rekod yang hilang.

Kemudian semak sama ada pertanyaan sampai ke titik akhir: sumber premis memerlukan laluan ke alamat resolver dan laluan balik, dan port 53 untuk UDP dan TCP harus dibenarkan di tempat dasar membenarkannya. NSG tidak boleh menyediakan rekod zon yang hilang, dan zon yang betul tidak boleh menjawab pertanyaan yang tidak pernah tiba.

Simpan FQDN yang diminta di sebelah resolver yang anda pilih semasa mendiagnosis, dan pisahkan tamat masa daripada jawapan negatif. Tamat masa ialah masalah laluan atau dasar. Jawapan negatif bermakna pertanyaan tiba dan ruang nama tidak sepadan. Urutan kerja: pautkan zon, tambah forwarder bersyarat, buka port 53 di kedua-dua arah, uji satu nama dari premis, dan hanya selepas itu lihat kebenaran aplikasi itu sendiri.