Apakah Azure VNet yang di-peer perlu gerbang VPN sendiri?
VNet yang di-peer dapat memakai gerbang VPN hub dengan SKU yang didukung dan satu pengaturan di setiap arah peering. Periksa rute efektif, bukan status peering.
Sebuah VNet spoke baru muncul, hub sudah memiliki gateway site-to-site yang berfungsi, dan pertanyaan yang jelas adalah apakah Anda harus membayar gateway kedua. Biasanya tidak: transit gateway memungkinkan spoke memakai gateway hub melalui peering. Tiga kondisi menentukan apakah itu akan berhasil, dan tidak satu pun terlihat dari lencana status peering. Konektivitas peering dan izin memakai gateway milik orang lain adalah pengaturan terpisah, jadi dua VM yang sudah bisa saling ping tidak membuktikan apa pun tentang jalur VPN.
Kondisi pertama: gateway, dan ketiadaan gateway di spoke
Azure mendukung transit gateway untuk SKU VPN Gateway selain Basic, dan peering regional maupun global dapat membawanya. Spoke memakai gateway yang bukan miliknya, sehingga tidak bisa punya gateway sendiri: jika sudah ada gateway di spoke, atau opsi gateway jarak jauh sudah dipilih, pengaturan transit yang Anda inginkan akan tidak tersedia atau tidak efektif. Periksa itu sebelum men-debug apa pun, karena kotak centang yang nonaktif adalah gejalanya, bukan kesalahannya. Baca SKU dan gateway yang ada terlebih dahulu, lalu lihat pengaturan peering.
Jangan hapus gateway spoke yang ada hanya agar opsi muncul sampai Anda tahu apa yang bergantung padanya. Urutan migrasi lebih penting daripada kotak centang.
Kondisi kedua: satu pengaturan di setiap arah peering
Peering adalah dua objek, satu di setiap VNet, dan pengaturan transit berada di sisi berbeda dari pasangan itu. Peering hub ke arah spoke harus mengizinkan gateway hub melayani spoke; peering spoke ke arah hub harus menerima gateway hub. panduan transit gateway Microsoft menamainya per arah, dan itulah satu-satunya cara menjaganya tetap benar:
| Peering direction | What to enable |
|---|---|
| Hub → spoke | Allow gateway transit on the hub's peering |
| Spoke → hub | Use remote gateways on the spoke's peering |
Kontrol berlabel remote berubah makna tergantung peering VNet mana yang Anda edit, jadi bacalah arahnya, bukan katanya. Atur kedua sisi, simpan, dan pastikan peering melaporkan terhubung di kedua tempat.
Kondisi ketiga: ruang alamat dan batas izin
Transit tidak dapat membuat prefiks tujuan yang sama berarti dua jaringan, jadi rentang hub, spoke, dan jaringan lokal harus saling terpisah sebelum hal ini berfungsi. VNet juga bisa berada di langganan atau penyewa yang berbeda; itu bukan larangan, tetapi identitas yang membuat atau memperbarui setiap peering memerlukan izin yang diperlukan pada jaringan tersebut. Perubahan lintas langganan sering gagal karena izin, dan kesalahan itu mudah salah dibaca sebagai masalah topologi.
Tuliskan rentang dan pemiliknya sebelum perubahan. Menebak salah satunya menghasilkan peering yang terhubung dan tidak merutekan apa pun.
Verifikasi dengan rute efektif, bukan dengan status peering
Lihat rute efektif pada antarmuka jaringan beban kerja spoke dan temukan prefiks jaringan lokal yang sebenarnya. Periksa tabel rute subnet dan apakah propagasi rute gateway dinonaktifkan, karena rute yang ditentukan pengguna atau perangkat inspeksi dapat menimpa jalur yang disarankan tanda peering. Lalu pastikan arah sebaliknya: jaringan lokal harus tahu cara mencapai prefiks spoke melalui koneksi site-to-site, baik melalui iklan yang dipelajari maupun melalui rute eksplisit dan entri jaringan terlindungi yang cocok pada perangkat pelanggan. Jika prefiks tidak ada di salah satu sisi, tanda peering bukanlah hal yang harus diubah.
Uji satu layanan dari beban kerja spoke dan ikuti balasannya. Pengujian dari gateway VPN atau dari VM hub menggunakan prefiks sumber dan jalur yang berbeda.
Jika topologi juga melayani klien point-to-site, validasi rute terpasangnya secara terpisah. Paket klien Windows mungkin perlu dibuat ulang setelah perubahan topologi, dan itu tugas perutean klien, bukan bukti bahwa berbagi gateway gagal.
Apa yang tidak diberikan oleh berbagi gateway
Transit gateway adalah kemudahan perutean, bukan otorisasi. Grup keamanan jaringan, filter lokal, dan aturan tingkat layanan tetap menentukan apa yang dapat dijangkau beban kerja spoke, jadi aktifkan layanan sumber-ke-tujuan yang spesifik alih-alih menganggap terowongan bersama mengizinkan segala sesuatu di belakangnya.
Peering juga tidak transitif seperti yang diharapkan orang. Menambahkan spoke lain, atau titik akhir privat, menghadirkan persyaratan perutean dan aksesnya sendiri yang tidak dicakup pengaturan transit yang ada.