DNS Azure P2S gagal saat resolver berada di VNet yang di-peer

Ping VM dan ia menjawab; tanyakan namanya dan klien berkata host tidak dikenal. Ketika resolver berada di jaringan virtual yang di-peer alih-alih di jaringan yang memuat gateway VPN, pasangan hasil itu memang diharapkan, dan tidak ada banyak pemecahan masalah resolver yang mengubahnya. Yang hilang adalah kontrak perutean yang ditahan peering secara default. Dua topologi tampak hampir identik di atas kertas, dan selisih antara berfungsi dan rusak adalah sepasang sakelar peering yang disetel ke arah yang benar.

Bayangkan laptop yang menerowong ke gateway di VNet2, sementara pengendali domain yang melayani DNS duduk di VNet1.

Dua topologi, satu perbedaan

Letakkan resolver di dalam jaringan virtual gateway itu sendiri dan nama akan terurai begitu terowongan naik. Tidak ada pengaturan peering yang ikut dalam pencarian itu.

Pindahkan resolver yang sama melintasi peering dan klien tetap mendapat jawaban dari VM sementara nama tetap tidak dikenal. Sertifikat, terowongan, dan klien tidak berubah. Satu-satunya yang berpindah adalah tempat resolver tinggal. Peering memberinya rute ke alamat itu, bukan kewenangan bagi gateway untuk membawa lalu lintas ke sana.

Sisi A: izinkan transit gateway pada pemilik gateway

Peering menyatukan dua jaringan virtual, tetapi sambungan itu tidak transitif untuk lalu lintas yang tiba melalui gateway, dan permintaan point-to-site tiba persis seperti itu. Karena itu gateway di VNet2 tidak berwenang menyerahkan pencarian ke VNet1 sampai desainnya mengizinkan. Izinnya adalah sakelar pada peering yang dimiliki jaringan yang memuat gateway.

Setel Allow gateway transit pada peering VNet2 menuju VNet1. Properti itu milik objek peering, bukan sumber daya gateway, jadi Anda membacanya dan mengubahnya di bilah peering. Itulah seluruh sisi A.

Sisi B: gunakan gateway jarak jauh pada peer

Separuh lainnya adalah cermin: pada peering VNet1 kembali ke VNet2, aktifkan Use remote gateways. Menyalakan tanda yang sama di kedua ujung, atau hanya di satu ujung, menyisakan jalur setengah jadi dan gejala asli tak tersentuh. Hanya jaringan dengan gateway VPN yang mengizinkan transit, dan peer adalah sisi yang memakainya.

Baca kedua properti pada kedua jaringan alih-alih memercayai bilah portal yang terakhir Anda buka.

Get-AzVirtualNetworkPeering -ResourceGroupName rg-core -VirtualNetworkName vnet2 `
  | Format-List Name,AllowGatewayTransit,UseRemoteGateways
Get-AzVirtualNetworkPeering -ResourceGroupName rg-core -VirtualNetworkName vnet1 `
  | Format-List Name,AllowGatewayTransit,UseRemoteGateways

Melihat pasangan itu berdampingan adalah cara tercepat menangkap setelan terbalik. Peering yang melaporkan AllowGatewayTransit false di sisi gateway menjelaskan seluruh kegagalan tanpa penangkapan paket.

Apa yang masih harus diterima klien

Perutean perlu dan tidak cukup, karena profil point-to-site juga harus memberikan klien alamat DNS yang menjawab setelah transit bekerja. Resolver platform bukan alamat itu: ia menjawab zona Azure Private DNS yang tertaut ke jaringan virtual, tetapi tidak untuk zona yang dihosting di server direktori Anda sendiri, dan itulah yang dipakai penerapan ini. Arahkan klien ke sana dan nama publik terurai dengan riang sementara host internal tetap tidak dikenal.

Tanyakan resolver dari laptop yang terhubung sebelum mengubah apa pun lagi.

nslookup dc01.corp.example 10.1.0.4

Batas waktu mengatakan jalur itu masih hilang. Jawaban otoritatif mendorong masalah kembali ke klien, biasanya sufiks yang tidak pernah ditambahkan, sehingga nama pendek berkelana ke resolver publik yang dengan riang menggagalkannya.

Bandingkan kontrak yang sama di sisi situs-ke-situs

Tidak ada yang khusus milik laptop di sini. Ganti klien dengan cabang di situs-ke-situs dan persyaratan dua sisi kembali: cabang tiba langsung di jaringan gateway, dan layanan dua jaringan jauhnya masih di balik peering.

Transit harus diberikan pada kedua peering, dan sakelar yang memberikannya berada pada peering, bukan pada jenis klien.

Sebelum menyalahkan gateway

Windows menyimpan daftar resolver per adaptor, jadi pastikan apa yang benar-benar diterima antarmuka terowongan sebelum menyalahkan gateway.

ipconfig /all
Get-DnsClientServerAddress -AddressFamily IPv4
ipconfig /flushdns

Jawaban negatif bertahan di cache lebih lama daripada perbaikan perutean, dan daftar sufiks yang basi terus mengirim kueri ke tempat yang tidak pernah menghosting zona itu. Bersihkan, tanyakan lagi, dan catat server mana yang menjawab.

Dua syarat lebih kecil menentukan apakah jalur bertahan: ruang alamat tidak boleh tumpang tindih, dan grup keamanan jaringan pada subnet resolver harus menerima kumpulan klien, yang hanyalah rentang sumber lain. Buktikan dengan pemeriksaan rute efektif dari sisi VM plus satu kueri langsung dari klien, agar masalah zona, masalah sufiks, atau filter tidak pernah dikira transit yang hilang.