Peering Azure atau VPN VNet ke VNet? Putuskan sebelum routing

Azure memberi Anda setidaknya dua cara menghubungkan dua jaringan virtual, dan keduanya bukan pengaturan yang dapat dipertukarkan pada objek yang sama. Peering menyatukan VNet di backbone Microsoft tanpa gateway; VPN VNet ke VNet menempatkan hubungan IPsec antara dua gateway yang Anda terapkan, ukur kapasitasnya, dan pantau. Keputusannya bermuara pada tiga syarat, dan jika Anda tidak dapat menjawab ketiganya sebelum menambahkan rute, Anda sedang membangun akal-akalan untuk model yang tidak pernah Anda pilih.

Tiga syarat yang menentukan model

Yang pertama adalah apakah ada bagian dari kebutuhan yang memerlukan batas IPsec milik Anda dan dapat Anda tunjuk. Yang kedua adalah apakah ruang alamat bersih dan kedua VNet hanya perlu saling berbicara. Yang ketiga adalah siapa pemilik jalur transit dan tagihan gateway. Jawablah dalam urutan itu, karena yang pertama dapat menyingkirkan peering seberapa menarik pun yang kedua terlihat.

Yang sama pada kedua model adalah aturan pengalamatan yang keras: ruang alamat VNet tidak boleh tumpang tindih. Baik peering maupun VPN VNet ke VNet bukan cara yang didukung untuk membuat dua rentang identik menjadi tidak ambigu, dan tumpang tindih memerlukan desain pemetaan atau desain ulang, bukan jenis koneksi lain.

Syarat 1: apakah Anda memerlukan batas IPsec milik sendiri?

Peering membawa lalu lintas melalui backbone privat Azure dan tidak memerlukan gateway VPN untuk koneksi peered itu sendiri. Itu pernyataan tentang transport, bukan pernyataan tentang enkripsi yang dapat Anda serahkan kepada auditor sebagai «kami menjalankan IPsec». Jika kebutuhan menyebut terowongan yang dikonfigurasi pelanggan, kebijakan IKE tertentu, atau batas yang berakhir pada peralatan yang Anda kendalikan, peering tidak memenuhinya, seprivat apa pun backbonenya.

VPN VNet ke VNet memang menyediakan batas itu: dua gateway, hubungan IPsec/IKE, kunci bersama, dan seluruh permukaan operasional yang menyertainya. Anda mewarisi status terowongan, kapasitas gateway, batas SKU, dan pemantauan yang membuktikan terowongan hidup. Itu jawaban yang benar ketika kebutuhan secara khusus tentang batas itu, yang dijelaskan dalam ikhtisar peering sebagai jenis koneksi yang berbeda dari peering.

Sama berhati-hatilah ke arah sebaliknya. «Kami perlu enkripsi antar-VNet» sering terpenuhi oleh TLS milik beban kerja itu sendiri, dan kemudian gateway menjadi biaya tanpa kebutuhan di belakangnya. Tuliskan kalimat yang akan dibaca auditor sebelum memilih mekanismenya.

Syarat 2: apakah topologinya langsung, atau ada yang perlu transit?

Peering tidak transitif. Dua VNet yang di-peer ke sebuah hub tidak dengan sendirinya terhubung satu sama lain, dan rute yang tampak bekerja di satu arah biasanya peering yang hanya mencapai Connected di satu sisi. Kedua sisi harus ada dan keduanya harus menunjukkan Connected, dan itulah hal pertama yang Anda periksa ketika lalu lintas menghilang diam-diam.

Jika kebutuhan adalah jangkauan on-premises melalui hub, transit gateway adalah desain terpisah dengan peran khusus: hub memiliki gateway, peering spoke mengizinkan transit gateway, dan spoke harus mengizinkan lalu lintas yang diteruskan. Itu properti pada peering, bukan konsekuensi otomatis dari menghubungkan VNet:

az network vnet peering create -g hub-rg -n hub-to-spoke1   --vnet-name hub-vnet --remote-vnet /subscriptions/SUB/resourceGroups/spoke-rg/providers/Microsoft.Network/virtualNetworks/spoke1-vnet   --allow-vnet-access --allow-gateway-transit --allow-forwarded-traffic

az network vnet peering list -g hub-rg --vnet-name hub-vnet -o table
az network nic show-effective-route-table -g spoke-rg -n app-nic -o table

Tabel rute efektif adalah jawaban jujur atas «apakah jalurnya ada?». Tabel itu menunjukkan jenis hop berikutnya yang benar-benar akan dipakai platform, sehingga peering yang tampak terkonfigurasi tetapi tidak terhubung muncul sebagai rute yang hilang atau salah, bukan sebagai misteri.

Syarat 3: siapa pemilik jalur transit dan tagihannya?

Setiap hop tambahan punya pemilik. Dengan peering, VNet baru berarti pasangan peering baru di kedua sisi dan, untuk transit, hub yang terus meneruskan lalu lintas serta tabel rute yang terus menunjuk ke sana. Dengan VPN, VNet baru berarti gateway lain atau koneksi lain pada gateway yang ada, dengan plafon kapasitasnya sendiri yang harus dipantau.

Biaya mengikuti bentuk yang sama tetapi bukan pos yang sama: tarif peering adalah koneksi dan transfer data, sedangkan VPN menambah jam gateway dan biaya transfernya sendiri. Bandingkan total untuk topologi yang benar-benar akan Anda jalankan selama setahun, termasuk terowongan kedua dan pemantauan, bukan harga satu koneksi hari ini. Sertakan pekerjaan yang tidak ditagih siapa pun: seseorang harus merotasi kunci, memantau status terowongan, dan menjawab peringatan pukul tiga pagi ketika gateway restart. Pos itulah yang biasanya memutuskan perdebatan, karena hanya itu yang tidak pernah muncul dalam penawaran.

Apa pun yang Anda pilih, uji tiga aliran: yang dimaksudkan, yang ditolak dan harus tetap ditolak, serta kasus pemulihan ketika gateway hub atau peering mati. Model yang hanya menjelaskan jalur mulus belum diverifikasi, melainkan didemonstrasikan.

Verifikasi pilihan terhadap klaimnya sendiri

Tulis satu kalimat yang menyebut model, batas, dan pemiliknya, lalu periksa bahwa keadaan yang diterapkan cocok dengannya. Untuk peering itu berarti kedua status peering Connected, rute efektif menunjukkan hop peering berikutnya untuk prefiks tujuan, dan tidak ada gateway di jalur. Untuk VPN VNet ke VNet itu berarti kedua koneksi Connected, kunci dan kebijakan yang cocok di kedua gateway, dan rute yang hop berikutnya adalah gateway jaringan virtual.

Jika pemeriksaan bertentangan dengan kalimat itu, perbaiki dulu kalimatnya. Sebagian besar kebingungan dalam desain ini berasal dari hibrida yang tidak dijelaskan siapa pun: peering untuk subnet beban kerja, VPN untuk satu layanan lama, dan tabel rute yang diam-diam mengutamakan salah satunya.