VPN Gateway klasik ke migrasi Azure Resource Manager

Gateway VPN sekarang dapat dimigrasikan dari model penyebaran klasik ke model penyebaran Resource Manager. Untuk informasi selengkapnya, lihat Model penyebaran Resource Manager. Dalam artikel ini, kita membahas cara bermigrasi dari penyebaran klasik ke model Resource Manager.

Penting

Anda tidak dapat lagi membuat gateway jaringan virtual baru untuk jaringan virtual model penyebaran klasik (manajemen layanan). Gateway jaringan virtual baru hanya dapat dibuat untuk jaringan virtual Resource Manager.

Gateway VPN dimigrasikan sebagai bagian dari migrasi VNet dari klasik ke Resource Manager. Migrasi ini dilakukan satu VNet pada satu waktu. Tidak ada persyaratan tambahan dalam hal alat atau prasyarat untuk bermigrasi. Langkah-langkah migrasi identik dengan migrasi VNet yang ada dan didokumenkan di halaman migrasi sumber daya IaaS.

Tidak ada waktu henti jalur data selama migrasi dan dengan demikian beban kerja yang ada terus berfungsi tanpa kehilangan konektivitas lokal selama migrasi. Alamat IP publik yang terkait dengan gateway VPN tidak berubah selama proses migrasi. Ini menyiratkan bahwa Anda tidak perlu mengonfigurasi ulang router lokal Anda setelah migrasi selesai.

Model Resource Manager berbeda dari model klasik dan terdiri dari gateway jaringan virtual, gateway jaringan lokal, dan sumber daya koneksi. Ini mewakili gateway VPN itu sendiri, situs lokal yang mewakili ruang alamat lokal dan konektivitas antara keduanya. Setelah migrasi selesai, gateway Anda tidak akan tersedia dalam model klasik dan semua operasi manajemen pada gateway jaringan virtual, gateway jaringan lokal, dan objek koneksi harus dilakukan menggunakan model Resource Manager.

Skenario yang didukung

Sebagian besar skenario konektivitas VPN umum dicakup oleh migrasi klasik ke Resource Manager. Skenario yang didukung meliputi:

  • Konektivitas titik ke situs
  • Konektivitas situs-ke-situs dengan VPN Gateway yang tersambung ke lokasi lokal
  • Konektivitas VNet-ke-VNet antara dua VNet menggunakan gateway VPN
  • Beberapa VNet tersambung ke lokasi lokal yang sama
  • Konektivitas multi-situs
  • Penerowongan paksa dapat diaktifkan

Skenario yang tidak didukung meliputi:

  • VNet dengan gateway ExpressRoute dan gateway VPN saat ini tidak didukung.
  • Skenario transit di mana ekstensi komputer virtual terhubung ke server lokal. Batasan konektivitas VPN transit dirinci di bagian berikutnya.

Catatan

Validasi CIDR dalam model Resource Manager lebih ketat daripada yang ada di model klasik. Sebelum bermigrasi, pastikan rentang alamat klasik yang diberikan sesuai dengan format CIDR yang valid sebelum memulai migrasi. CIDR dapat divalidasi menggunakan validator CIDR umum. VNet atau situs lokal dengan rentang CIDR yang tidak valid saat dimigrasikan menghasilkan status gagal.

Migrasi konektivitas VNet-ke-VNet

Konektivitas VNet-ke-VNet dalam model penyebaran klasik dicapai dengan membuat representasi situs lokal dari VNet yang terhubung. Pelanggan diharuskan membuat dua situs lokal yang mewakili dua VNet yang perlu dihubungkan bersama-sama. Ini kemudian terhubung ke VNet yang sesuai menggunakan terowongan IPsec untuk membangun konektivitas antara dua VNet. Model ini memiliki tantangan pengelolaan, karena setiap rentang alamat berubah dalam satu VNet juga harus dipertahankan dalam representasi situs lokal yang sesuai. Dalam model Resource Manager, solusi ini tidak lagi diperlukan. Koneksi antara dua VNet dapat langsung dicapai menggunakan jenis koneksi 'Vnet2Vnet' di sumber daya Koneksi ion.

Diagram showing VNet-to-VNet migration.

Selama migrasi VNet, kami mendeteksi bahwa entitas yang terhubung ke gateway VPN VNet saat ini adalah VNet lain. Kami memastikan bahwa setelah migrasi kedua VNet selesai, Anda tidak lagi melihat dua situs lokal yang mewakili VNet lainnya. Model klasik dua gateway VPN, dua situs lokal, dan dua koneksi di antaranya diubah ke model Resource Manager dengan dua gateway VPN dan dua koneksi jenis Vnet2Vnet.

Konektivitas VPN transit

Anda dapat mengonfigurasi gateway VPN dalam topologi sedemikian rupa sehingga konektivitas lokal untuk VNet dicapai dengan menyambungkan ke VNet lain yang terhubung langsung ke lokal. Ini adalah konektivitas VPN transit, di mana instans di VNet pertama terhubung ke sumber daya lokal melalui transit ke gateway VPN di VNet yang terhubung langsung ke lokal. Untuk mencapai konfigurasi ini dalam model penyebaran klasik, Anda perlu membuat situs lokal yang memiliki awalan agregat yang mewakili VNet yang terhubung dan ruang alamat lokal. Situs lokal representasi ini kemudian terhubung ke VNet untuk mencapai konektivitas transit. Model klasik juga memiliki tantangan pengelolaan yang sama karena setiap perubahan dalam rentang alamat lokal juga harus dipertahankan di situs lokal yang mewakili agregat VNet dan lokal. Pengenalan dukungan BGP di gateway yang didukung Resource Manager menyederhanakan pengelolaan, karena gateway yang terhubung dapat mempelajari rute dari lokal tanpa modifikasi manual ke prefiks.

Diagram showing transit routing scenario.

Karena kami mengubah konektivitas VNet-ke-VNet tanpa memerlukan situs lokal, skenario transit kehilangan konektivitas lokal untuk VNet yang secara tidak langsung terhubung ke lokal. Hilangnya konektivitas dapat dimitigasi dengan dua cara berikut, setelah migrasi selesai:

  • Aktifkan BGP pada gateway VPN yang tersambung bersama dan ke lokasi lokal. Mengaktifkan BGP memulihkan konektivitas tanpa perubahan konfigurasi lainnya karena rute dipelajari dan diiklankan antara gateway VNet. Perhatikan bahwa opsi BGP hanya tersedia di SKU Standar dan yang lebih tinggi.
  • Buat koneksi eksplisit dari VNet yang terpengaruh ke gateway jaringan lokal yang mewakili lokasi lokal. Ini juga akan memerlukan perubahan konfigurasi pada router lokal untuk membuat dan mengonfigurasi terowongan IPsec.

Langkah berikutnya

Setelah mempelajari tentang dukungan migrasi gateway VPN, buka migrasi sumber daya IaaS yang didukung platform dari klasik ke Resource Manager untuk memulai.