Panduan untuk Private Link dan DNS di Azure Virtual WAN

Azure Private Link

Azure DNS

Azure Firewall

Azure Virtual WAN

Azure Private Link memungkinkan klien mengakses layanan platform as a service (PaaS) Azure langsung dari jaringan virtual privat tanpa menggunakan alamat IP publik. Untuk setiap layanan, Anda mengonfigurasi titik akhir privat yang menggunakan alamat IP privat dari jaringan Anda. Klien kemudian dapat menggunakan titik akhir privat untuk terhubung secara privat ke layanan.

Klien terus menggunakan nama domain yang sepenuhnya memenuhi syarat (FQDN) dari layanan untuk menyambungkannya. Anda mengonfigurasi DNS di jaringan Anda untuk menyelesaikan FQDN layanan ke alamat IP privat titik akhir privat.

Desain jaringan Anda dan, khususnya, konfigurasi DNS Anda, adalah faktor utama dalam mendukung konektivitas titik akhir privat ke layanan. Artikel ini adalah salah satu dari serangkaian artikel yang memberikan panduan tentang menerapkan berbagai skenario Private Link. Bahkan jika tidak ada skenario yang cocok dengan situasi Anda dengan tepat, Anda harus dapat menyesuaikan desain untuk memenuhi kebutuhan Anda.

Memulai topologi jaringan

Topologi jaringan awal adalah arsitektur jaringan yang berfungsi sebagai titik awal untuk semua skenario dalam rangkaian artikel ini. Arsitekturnya adalah jaringan hub-spoke khas yang menggunakan Azure Virtual WAN.

Gambar 1: Memulai topologi jaringan untuk semua titik akhir privat dan skenario DNS

Unduh file Visio arsitektur ini. Topologi ini memiliki karakteristik berikut:

Ini adalah jaringan hub-spoke yang diimplementasikan dengan Azure Virtual WAN.
Ada dua wilayah, masing-masing dengan hub virtual aman Azure Firewall regional.
Setiap hub virtual regional yang aman memiliki pengaturan keamanan berikut untuk koneksi Azure Virtual Network:
- Lalu lintas internet: Diamankan oleh Azure Firewall - Semua lalu lintas keluar ke aliran internet melalui firewall hub regional.
- Lalu lintas privat: Diamankan oleh Azure Firewall - Semua lalu lintas yang transit dari spoke ke spoke mengalir melalui firewall hub regional.
Setiap hub virtual regional diamankan dengan Azure Firewall. Firewall hub regional memiliki pengaturan berikut:
- Server DNS: Default (disediakan Azure) - Firewall hub regional secara eksplisit menggunakan Azure DNS untuk resolusi FQDN dalam kumpulan aturan.
- Proksi DNS: Diaktifkan - Firewall hub regional merespons kueri DNS pada port 53. Ini meneruskan kueri ke Azure DNS untuk nilai yang tidak di-cache.
- Firewall mencatat evaluasi aturan dan permintaan proksi DNS ke ruang kerja Analitik Log yang berada di wilayah yang sama. Pengelogan peristiwa ini adalah persyaratan pengelogan keamanan jaringan umum.
Setiap spoke jaringan virtual yang terhubung memiliki server DNS default yang dikonfigurasi untuk menjadi alamat IP privat firewall hub regional. Jika tidak , evaluasi aturan FQDN dapat tidak sinkron.

Perutean multi-wilayah

Hub Virtual WAN aman memiliki dukungan terbatas untuk konektivitas antar-hub ketika ada beberapa hub virtual yang aman. Batasan ini memengaruhi skenario multi-hub, intra-wilayah, dan lintas wilayah. Dengan demikian, topologi jaringan tidak secara langsung memfasilitasi pemfilteran lalu lintas wilayah privat melalui Azure Firewall. Dukungan untuk kemampuan ini dikirimkan dengan menggunakan niat perutean hub Virtual WAN dan kebijakan perutean. Kemampuan ini saat ini dalam pratinjau.

Untuk rangkaian artikel ini, asumsinya adalah bahwa lalu lintas aman internal tidak melintasi beberapa hub. Lalu lintas yang harus melintasi beberapa hub harus melakukannya pada topologi paralel yang tidak memfilter lalu lintas privat melalui hub virtual yang aman, tetapi memungkinkannya melewatinya sebagai gantinya.

Menambahkan jaringan spoke

Saat Anda menambahkan jaringan spoke, jaringan tersebut mengikuti batasan yang ditentukan dalam topologi jaringan awal. Secara khusus, setiap jaringan spoke dikaitkan dengan tabel rute default yang ada di hub regionalnya, dan firewall dikonfigurasi untuk mengamankan lalu lintas internet dan privat. Cuplikan layar berikut menunjukkan contoh konfigurasi:

Gambar 2: Konfigurasi keamanan untuk koneksi jaringan virtual di hub virtual

Tantangan utama

Topologi jaringan awal menciptakan tantangan untuk mengonfigurasi DNS untuk titik akhir privat.

Meskipun penggunaan Virtual WAN memberi Anda pengalaman hub terkelola, tradeoff adalah bahwa ada kemampuan terbatas untuk memengaruhi konfigurasi hub virtual atau kemampuan untuk menambahkan lebih banyak komponen ke dalamnya. Topologi hub-spoke tradisional memungkinkan Anda mengisolasi beban kerja dalam spoke sambil berbagi layanan jaringan umum, seperti rekaman DNS, di hub yang dikelola sendiri. Anda biasanya menautkan zona DNS privat ke jaringan hub sehingga Azure DNS dapat mengatasi alamat IP titik akhir privat untuk klien.

Namun, tidak dimungkinkan untuk menautkan zona DNS privat ke hub Virtual WAN, sehingga resolusi DNS apa pun yang terjadi dalam hub tidak mengetahui zona privat. Secara khusus, ini adalah masalah untuk Azure Firewall, penyedia DNS yang dikonfigurasi untuk spoke beban kerja, yang menggunakan DNS untuk resolusi FQDN.

Saat Anda menggunakan hub Virtual WAN, tampaknya intuitif bahwa Anda akan menautkan zona DNS privat ke jaringan virtual spoke tempat beban kerja mengharapkan resolusi DNS. Namun, seperti yang disebutkan dalam arsitektur, proksi DNS diaktifkan pada firewall regional dan diharapkan semua spoke menggunakan firewall regional mereka sebagai sumber DNS mereka. Azure DNS dipanggil dari firewall alih-alih dari jaringan beban kerja, sehingga tautan zona DNS privat apa pun di jaringan beban kerja tidak digunakan dalam resolusi.

Catatan

Untuk mengonfigurasi firewall regional menjadi penyedia dns spoke, atur server DNS kustom di jaringan virtual spoke untuk menunjuk ke IP privat firewall alih-alih ke nilai Azure DNS normal.

Mengingat kompleksitas yang dihasilkan dari mengaktifkan proksi DNS pada firewall regional, mari kita tinjau alasan untuk mengaktifkannya.

Aturan jaringan Azure Firewall mendukung batas berbasis FQDN untuk mengontrol lalu lintas keluar yang tidak ditangani aturan aplikasi dengan lebih tepat. Fitur ini mengharuskan proksi DNS diaktifkan. Penggunaan umum adalah membatasi lalu lintas Network Time Protocol (NTP) ke titik akhir yang diketahui, seperti time.windows.com.
Tim keamanan dapat memperoleh manfaat dari pengelogan permintaan DNS. Azure Firewall memiliki dukungan bawaan untuk pengelogan permintaan DNS, jadi mengharuskan semua sumber daya spoke menggunakan Azure Firewall sebagai penyedia DNS mereka memastikan cakupan pengelogan yang luas.

Untuk mengilustrasikan tantangan, bagian berikut menjelaskan dua konfigurasi. Ada contoh sederhana yang berfungsi, dan yang lebih kompleks yang tidak, tetapi kegagalannya bersifat instruktif.

Skenario kerja

Contoh berikut adalah konfigurasi titik akhir privat dasar. Jaringan virtual berisi klien yang memerlukan penggunaan layanan PAAS dengan menggunakan titik akhir privat. Zona DNS privat yang ditautkan ke jaringan virtual memiliki catatan A yang menyelesaikan FQDN layanan ke alamat IP privat titik akhir privat. Diagram berikut mengilustrasikan alur.

Gambar 3: Konfigurasi DNS dasar untuk titik akhir privat

Unduh file Visio arsitektur ini.

Klien mengeluarkan permintaan untuk stgworkload00.blob.core.windows.net.
Azure DNS, server DNS yang dikonfigurasi untuk jaringan virtual, dikueri untuk alamat IP untuk stgworkload00.blob.core.windows.net.

Menjalankan perintah berikut dari komputer virtual (VM) menggambarkan bahwa VM dikonfigurasi untuk menggunakan Azure DNS (168.63.129.16) sebagai penyedia DNS.
```
resolvectl status eth0

Link 2 (eth0)
      Current Scopes: DNS
  Current DNS Server: 168.63.129.16
         DNS Servers: 168.63.129.16    
```
Zona DNS privat privatelink.blob.core.windows.net ditautkan ke VNet Beban Kerja, sehingga Azure DNS menggabungkan rekaman dari Workload VNet dalam responsnya.
Karena catatan A ada di zona DNS privat yang memetakan FQDN, stgworkload00.privatelink.blob.core.windows.net, ke IP privat titik akhir privat, alamat IP privat 10.1.2.4 dikembalikan.

Menjalankan perintah berikut dari VM menyelesaikan FQDN akun penyimpanan ke alamat IP privat titik akhir privat.
```
resolvectl query stgworkload00.blob.core.windows.net

stgworkload00.blob.core.windows.net: 10.1.2.4   -- link: eth0
                                    (stgworkload00.privatelink.blob.core.windows.net)
```
Permintaan dikeluarkan ke alamat IP privat titik akhir privat yang, dalam hal ini, adalah 10.1.2.4.
Permintaan dirutekan melalui Private Link ke akun penyimpanan.

Desain berfungsi karena Azure DNS:

Adalah server DNS yang dikonfigurasi untuk jaringan virtual.
Mengetahui zona DNS privat yang ditautkan.
Mengatasi kueri DNS dengan menggunakan nilai zona.

Skenario non-pengerjaan

Contoh berikut adalah upaya naif untuk menggunakan titik akhir privat dalam topologi jaringan awal. Tidak dimungkinkan untuk menautkan zona DNS privat ke hub Virtual WAN. Oleh karena itu, ketika klien dikonfigurasi untuk menggunakan firewall sebagai server DNS mereka, permintaan DNS diteruskan ke Azure DNS dari dalam hub virtual, yang tidak memiliki zona DNS privat yang ditautkan. Azure DNS tidak tahu cara mengatasi kueri selain dengan menyediakan default, yang merupakan alamat IP publik.

Gambar 4: Upaya naif untuk menggunakan titik akhir privat dalam topologi jaringan awal

Unduh file Visio arsitektur ini.

Klien mengeluarkan permintaan untuk stgworkload00.blob.core.windows.net.

Menjalankan perintah berikut dari VM menggambarkan bahwa VM dikonfigurasi untuk menggunakan firewall hub virtual sebagai penyedia DNS.
```
resolvectl status eth0

Link 2 (eth0)
      Current Scopes: DNS
  Current DNS Server: 10.100.0.132
         DNS Servers: 10.100.0.132    
```
Firewall mengaktifkan Proksi DNS dengan pengaturan default untuk meneruskan permintaan ke Azure DNS. Permintaan diteruskan ke Azure DNS.
Azure DNS tidak dapat mengatasi stgworkload00.blob.core.windows.net ke alamat IP privat titik akhir privat karena:
1. Zona DNS privat tidak dapat ditautkan ke hub Virtual WAN.
2. Azure DNS tidak mengetahui zona DNS privat yang ditautkan ke jaringan virtual beban kerja, karena server DNS yang dikonfigurasi untuk jaringan virtual beban kerja adalah Azure Firewall. Azure DNS merespons dengan alamat IP publik akun penyimpanan.
Menjalankan perintah berikut dari VM menyelesaikan FQDN akun penyimpanan ke IP publik akun penyimpanan.
```
resolvectl query stgworkload00.blob.core.windows.net

stgworkload00.blob.core.windows.net: 52.239.174.228 -- link: eth0
                                    (blob.bn9prdstr08a.store.core.windows.net)
```
Karena Azure Firewall mem-proksi kueri DNS, kita dapat mencatatnya. Berikut ini adalah contoh log Proksi DNS Azure Firewall.
```
DNS Request: 10.1.0.4:60137 - 46023 A IN stgworkload00.blob.core.windows.net. udp 63 false 512 NOERROR qr,rd,ra 313 0.009424664s
DNS Request: 10.1.0.4:53145 - 34586 AAAA IN blob.bn9prdstr08a.store.core.windows.net. udp 69 false 512 NOERROR qr,aa,rd,ra 169 0.000113s    
```
Klien tidak menerima alamat IP privat untuk titik akhir Private Link dan tidak dapat membuat koneksi privat ke akun penyimpanan.

Perilaku di atas diharapkan. Ini adalah masalah yang ditangani skenario.

Skenario

Meskipun solusi untuk masalah ini serupa, berjalan melalui skenario beban kerja umum menunjukkan bagaimana solusi mengatasi persyaratan dari berbagai situasi. Sebagian besar skenario terdiri dari klien yang mengakses satu atau beberapa layanan PaaS melalui titik akhir privat. Mereka mematuhi topologi jaringan awal, tetapi berbeda dalam persyaratan beban kerja mereka. Skenario dimulai dengan sederhana, dengan klien yang mengakses satu layanan PaaS regional. Mereka menjadi lebih kompleks secara bertahap, menambahkan lebih banyak visibilitas jaringan, wilayah, dan layanan PaaS.

Dalam sebagian besar skenario, klien diimplementasikan sebagai VM, dan layanan PaaS yang diakses klien adalah akun penyimpanan. Anda harus mempertimbangkan VM sebagai stand-in untuk sumber daya Azure apa pun yang memiliki NIC yang diekspos pada jaringan virtual, seperti Virtual Machine Scale Sets, node Azure Kubernetes Service, atau layanan lain yang merutekan dengan cara yang sama.

Penting

Implementasi Private Link untuk akun Azure Storage mungkin berbeda dari layanan PaaS lainnya dengan cara yang halus, tetapi selaras dengan banyak orang. Misalnya, beberapa layanan menghapus catatan FQDN saat diekspos melalui Private Link, yang mungkin mengakibatkan perilaku yang berbeda, tetapi perbedaan tersebut biasanya bukan faktor dalam solusi untuk skenario ini.

Setiap skenario dimulai dengan status akhir yang diinginkan dan merinci konfigurasi yang diperlukan untuk mendapatkan dari topologi jaringan awal ke status akhir yang diinginkan. Solusi untuk setiap skenario memanfaatkan pola ekstensi hub virtual. Pola ini membahas cara mengekspos layanan bersama dengan cara yang terisolasi dan aman, sebagai ekstensi konseptual ke hub regional. Tabel berikut berisi tautan ke pola ekstensi hub virtual dan skenario.

Panduan	Deskripsi
Wilayah tunggal, PaaS khusus	Beban kerja dalam satu wilayah mengakses satu sumber daya PaaS khusus.

Langkah berikutnya

Membaca wilayah tunggal, skenario sumber daya PaaS khusus

Panduan untuk Private Link dan DNS di Azure Virtual WAN