DNS Azure P2S gagal apabila resolver berada dalam VNet yang di-peer

Klien boleh mencapai rangkaian mayanya sendiri dan masih gagal menyelesaikan nama dalam rangkaian yang di-peer. Peering bukan transit gateway sehingga kedua-dua pihak bersetuju.

Ping VM dan ia menjawab; tanya namanya dan klien berkata hos itu tidak dikenali. Apabila resolver berada dalam rangkaian maya yang di-peer dan bukan dalam rangkaian yang mengandungi gateway VPN, pasangan hasil itu memang dijangka, dan tiada berapa banyak penyelesaian masalah resolver dapat mengubahnya. Yang hilang ialah kontrak penghalaan yang ditahan peering secara lalai. Dua topologi kelihatan hampir serupa di atas kertas, dan jurang antara berfungsi dan rosak ialah sepasang suis peering yang ditetapkan ke arah yang betul.

Bayangkan sebuah komputer riba yang menyalurkan terowong ke gateway dalam VNet2, sementara pengawal domain yang menyediakan DNS duduk dalam VNet1.

Dua topologi, satu perbezaan

Letakkan resolver dalam rangkaian maya gateway itu sendiri dan nama akan diselesaikan sebaik terowong naik. Tiada tetapan peering mengambil bahagian dalam carian itu.

Alihkan resolver yang sama merentasi peering dan klien masih menerima jawapan daripada VM sementara nama kekal tidak dikenali. Sijil, terowong dan klien tidak berubah. Satu-satunya yang bergerak ialah tempat resolver tinggal. Peering memberinya laluan ke alamat itu, bukan kuasa kepada gateway untuk membawa trafik ke sana.

Sisi A: benarkan transit gateway pada pemilik gateway

Peering menyatukan dua rangkaian maya, tetapi sambungan itu tidak transitif untuk trafik yang tiba melalui gateway, dan permintaan titik-ke-tapak tiba tepat begitu. Oleh itu gateway dalam VNet2 tidak berhak menyerahkan carian kepada VNet1 sehingga reka bentuk membenarkannya. Kebenaran itu ialah suis pada peering yang dimiliki rangkaian yang mengandungi gateway.

Tetapkan Allow gateway transit pada peering VNet2 menuju VNet1. Sifat itu milik objek peering, bukan sumber gateway, jadi anda membacanya dan mengubahnya dalam bilah peering. Itulah keseluruhan sisi A.

Sisi B: gunakan gateway jauh pada rakan sebaya

Separuh lagi ialah cermin: pada peering VNet1 kembali ke VNet2, aktifkan Use remote gateways. Menghidupkan bendera yang sama pada kedua-dua hujung, atau hanya satu hujung, meninggalkan laluan separuh siap dan gejala asal tidak tersentuh. Hanya rangkaian dengan gateway VPN membenarkan transit, dan rakan sebaya ialah sisi yang menggunakannya.

Baca kedua-dua sifat pada kedua-dua rangkaian daripada mempercayai 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 bersebelahan ialah cara terpantas menangkap tetapan terbalik. Peering yang melaporkan AllowGatewayTransit false di sisi gateway menjelaskan seluruh kegagalan tanpa tangkapan paket.

Apa yang masih perlu diterima klien

Penghalaan perlu dan tidak mencukupi, kerana profil titik-ke-tapak juga mesti memberikan klien alamat DNS yang menjawab setelah transit berfungsi. Resolver platform bukan alamat itu: ia menjawab zon Azure Private DNS yang dipautkan ke rangkaian maya, tetapi tiada apa-apa untuk zon yang dihoskan pada pelayan direktori anda sendiri, dan itulah yang digunakan oleh penggunaan ini. Halakan klien ke sana dan nama awam diselesaikan dengan riang sementara hos dalaman kekal tidak dikenali.

Tanya resolver daripada komputer riba yang bersambung sebelum mengubah apa-apa lagi.

nslookup dc01.corp.example 10.1.0.4

Tamat masa mengatakan laluan itu masih tiada. Jawapan berwibawa menolak masalah kembali kepada klien, biasanya akhiran yang tidak pernah ditambah, jadi nama pendek bergerak ke resolver awam yang dengan riang menggagalkannya.

Bandingkan kontrak yang sama di sisi tapak-ke-tapak

Tiada satu pun daripada ini khusus milik komputer riba. Gantikan klien dengan cawangan di tapak-ke-tapak dan syarat dua sisi kembali: cawangan tiba terus ke rangkaian gateway, dan perkhidmatan dua rangkaian jauhnya masih di belakang peering.

Transit mesti diberikan pada kedua-dua peering, dan suis yang memberikannya berada pada peering dan bukan pada jenis klien.

Sebelum menyalahkan gateway

Windows menyimpan senarai resolver bagi setiap penyesuai, jadi sahkan apa yang sebenarnya diterima antara muka terowong sebelum menyalahkan gateway.

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

Jawapan negatif bertahan dalam cache lebih lama daripada pembetulan penghalaan, dan senarai akhiran yang basi terus menghantar pertanyaan ke tempat yang tidak pernah menghoskan zon itu. Kosongkan, tanya lagi, dan catat pelayan mana yang menjawab.

Dua syarat yang lebih kecil menentukan sama ada laluan bertahan: ruang alamat tidak boleh bertindih, dan kumpulan keselamatan rangkaian pada subnet resolver mesti menerima kolam klien, yang hanyalah julat sumber lain. Buktikan dengan pemeriksaan laluan berkesan dari sisi VM serta satu pertanyaan terus daripada klien, supaya masalah zon, masalah akhiran atau penapis tidak pernah disangka transit yang hilang.

Artikel berkaitan