Mengapa point-to-site membutuhkan gateway Azure VPN berbasis rute

Gateway berbasis kebijakan membangun tunnel IPsec yang dipilih oleh pemilih lalu lintas, dan tidak memiliki antarmuka untuk menyerahkan rute klien. Koneksi point-to-site adalah fitur perutean: gateway memiliki kumpulan alamat klien dan memasang rute ke klien tersebut di jaringan virtual. Ketidakcocokan itulah sebabnya portal tidak menampilkan opsi untuk menambahkannya. Tidak ada yang dapat diubah pada gateway yang ada untuk menghasilkan antarmuka itu, jadi perubahannya adalah penggantian, bukan penyuntingan konfigurasi.

Urutannya lebih penting daripada langkah individual. Jika urutannya salah, gangguan site-to-site akan melewati jendela pemeliharaan.

Apa yang sebenarnya dilakukan gateway berbasis kebijakan

Gateway berbasis kebijakan mencocokkan paket dengan pemilih lalu lintas yang dikonfigurasi pada koneksi dan mengirim kecocokan ke satu tunnel. Tidak ada antarmuka tunnel dengan alamat, dan tidak ada rute per klien yang muncul di mana pun di jaringan virtual. Tabel rute hanya menerima prefiks lokal yang menunjuk ke gateway. Model itu memadai untuk koneksi site-to-site antara dua ruang alamat tetap.

Gateway berbasis rute bekerja sebaliknya: ia menyediakan antarmuka tunnel, dan rute menentukan apa yang masuk ke dalamnya. Point-to-site, dan desain apa pun yang kumpulan peernya berubah, bergantung pada keberadaan antarmuka itu.

Mengapa kumpulan klien membutuhkan antarmuka itu

Saat laptop terhubung, gateway memberinya alamat dari kumpulan point-to-site. Jaringan virtual kemudian membutuhkan rute yang menyatakan bahwa alamat ini dapat dijangkau melalui gateway. Tanpa antarmuka tunnel tidak ada tempat untuk menempelkan rute itu.

Kumpulan itu berasal dari rentang yang Anda tentukan, dan gateway mengalokasikan darinya. Jika rentang itu tumpang tindih dengan jaringan lokal atau jaringan virtual yang di-peering, konfliknya baru muncul setelah klien terhubung, yang merupakan momen buruk untuk menemukannya. Reservasikan kumpulan itu sebelum migrasi dimulai.

Tipe juga bukan pengaturan per koneksi. Satu gateway memiliki satu tipe, dan setiap koneksi yang dipegangnya berperilaku sesuai dengan itu, jadi desain campuran membutuhkan gateway kedua, bukan koneksi kedua.

Tipe ditetapkan saat pembuatan

Microsoft menyatakan bahwa gateway jaringan virtual tidak dapat diubah antara berbasis kebijakan dan berbasis rute setelah penerapan. Tidak ada perintah konversi dan tidak ada tombol di portal. Membuat gateway kedua di subnet yang sama juga bukan jalan pintas, karena Azure mengizinkan satu gateway per jaringan virtual. Karena itu migrasinya adalah hapus, bangun ulang, sambungkan ulang.

Itu juga memasukkan keputusan SKU ke dalam pembangunan yang sama. Pindah ke SKU yang lebih besar nanti adalah penggantian gateway lain dengan gangguan lain.

Satu gateway, satu GatewaySubnet

Gateway berada di subnet bernama GatewaySubnet, dan hanya satu gateway yang menempatinya. Menentukan ukuran subnet itu termasuk persiapan, karena SKU yang lebih besar membutuhkan lebih banyak alamat dan subnet tidak dapat diperkecil setelahnya. Catat pengaturan site-to-site saat ini, kunci bersama, gateway jaringan lokal, dan rute efektif sebelum menyentuh apa pun. Lalu perlakukan jendela itu sebagai gangguan, karena tunnel site-to-site tetap mati sampai koneksi baru dikonfigurasi.

Urutan pembangunan ulang yang menjaga gangguan tetap terbatas: buat gateway berbasis rute, buat ulang koneksi site-to-site ke gateway jaringan lokal yang sama, konfirmasi tunnel dan satu permintaan host-ke-host, lalu baru tambahkan point-to-site dan buat paket klien baru.

Apa yang tidak diperbaiki oleh penggantian

Batasan kedua milik peer, bukan Azure. Perangkat lokal berbasis kebijakan hanya dapat menjangkau jaringan virtual yang terhubung dengannya, dan tidak dapat transit ke jaringan lokal lain atau jaringan virtual lain melalui gateway yang sama. Mengganti sisi Azure tidak mengubah apa yang dapat dipilih peer.

Jika kebutuhannya benar-benar transit antar site, jawabannya adalah perangkat peer berbasis rute atau topologi di mana setiap tujuan berakhir terpisah. Selesaikan itu sebelum menjanjikan tanggal, karena penggantian gateway saja tidak akan memberikannya.

Urutan operasi dan pemeriksaan

Verifikasi setiap kemampuan secara terpisah. Pertama status tunnel site-to-site dan satu permintaan host-ke-host, lalu koneksi point-to-site dan satu sumber daya privat, lalu jalur transit apa pun yang diklaim desain. Status gateway hijau hanya membuktikan bahwa asosiasi keamanan naik, tidak lebih. Pertahankan pemeriksaan dalam urutan itu agar kegagalan menunjuk ke tahap yang memasukkannya.

Buat ulang paket klien setelah setiap perubahan topologi, dan jaga kumpulan tetap jauh dari setiap rentang lokal dan yang di-peering. Batasan dan perbedaan SKU dikumpulkan dalam referensi pengaturan Azure VPN Gateway.