RRAS di VM Azure tidak didukung: periksa sebelum mendesain

Anda membuka portal, menyebarkan Windows Server 2022 ke subnet, dan peran Remote Access terpasang dengan bersih. Urutan itu membuktikan bahwa penginstal berfungsi, bukan bahwa Microsoft mendukung konfigurasi tersebut. Panduan dukungan perangkat lunak server yang diterbitkan untuk mesin virtual Azure mencantumkan RRAS di antara fitur Windows Server yang tidak didukung pada VM Azure, dan itu keputusan arsitektur, bukan detail pemecahan masalah. Terowongan yang menyala tidak memindahkan penerapan ke dalam batas dukungan.

Panduan di bawah ini dimulai dari halaman dukungan, lalu bergerak keluar menuju persyaratan dan opsi penggantian.

Mulai dari halaman dukungan, bukan dari lab

Baca panduan dukungan VM Azure sebelum Anda menentukan ukuran apa pun. Panduan itu memisahkan produk, peran, dan fitur yang didukung alih-alih memperlakukan Windows Server sebagai satu blok tanpa pembedaan. Perhatikan baris mana beban kerja yang Anda rencanakan benar-benar berada, karena dua komponen yang tampak terkait di konsol bisa berada di baris berbeda.

Tulis kutipan itu ke dokumen desain selama halaman masih terbuka. Status dukungan adalah fakta dengan sumber, dan tinjauan desain yang tidak dapat mengutipnya akan dikalahkan oleh pihak yang memiliki demo.

Pisahkan dukungan OS dari dukungan peran dan fitur

Panduan yang sama mencantumkan Network Policy and Access Services di antara peran yang didukung sekaligus mencantumkan RRAS secara terpisah sebagai tidak didukung. Kedua entri itu menjelaskan hal berbeda, dan menggabungkannya menjadi “akses jarak jauh didukung” adalah cara sebuah proyek disetujui berdasarkan salah baca. Sistem operasi yang didukung tidak mengatakan apa pun tentang fitur yang memiliki barisnya sendiri.

Batasan itu juga lebih sempit daripada yang kadang dikutip. Batasan itu menyangkut fitur tersebut yang berjalan di dalam VM Azure; bukan berarti jaringan privat tidak dapat terhubung ke Azure, dan bukan berarti RRAS tidak didukung di mana pun. Lab lama yang meneruskan paket dengan benar adalah bukti tentang paket, bukan tentang pernyataan dukungan.

Pisahkan kedua pertanyaan itu selama sisa proyek: apakah berfungsi, dan apakah didukung. Anda akan membutuhkan jawaban berbeda dan kadang pemilik berbeda untuk masing-masing.

Tuliskan apa yang sebenarnya harus dilakukan desain

Sebelum memilih pengganti, ubah daftar situs menjadi persyaratan yang dapat dipakai mengukur produk:

• Protokol terowongan yang sudah dipakai perangkat cabang, dan apakah ada situs yang membutuhkan perutean dinamis.
• Prefiks jarak jauh, termasuk ruang alamat yang tumpang tindih yang membutuhkan penerjemahan, bukan perutean.
• Pertukaran rute dengan Azure, dan siapa yang memiliki setiap entri tabel rute.
• Throughput dan jumlah koneksi yang harus ditahan jam tersibuk.
• Perilaku failover yang disepakati pemilik situs, bukan hanya yang dapat Anda bangun.

NAT adalah butir yang dilewati lalu menentukan seluruh desain. Perangkat yang dapat membangun IPsec tetap dapat menerjemahkan alamat secara berbeda dari penerapan RRAS yang digantikannya, dan itu mengubah apa yang dilihat cabang sebagai alamat sumber serta apa yang dicatat log Anda.

Bawa daftar itu ke pemilik jaringan dan konfirmasikan sebelum diskusi produk apa pun. Persyaratan yang ambigu mengubah setiap perbandingan vendor menjadi perdebatan preferensi.

Evaluasi pengganti terhadap persyaratan itu

Layanan konektivitas terkelola Azure dan peralatan jaringan virtual yang didukung vendor keduanya perlu dinilai terhadap daftar yang sama. Jangan menganggap salah satunya setara langsung dengan VM RRAS hanya karena dapat mengakhiri IPsec: model NAT dan kepemilikan rute serta desain ketersediaan tinggi menentukan bagaimana situs yang ada terhubung dan ke mana balasan mereka kembali. Nilai setiap kandidat di atas kertas terhadap daftar itu dan tuliskan persyaratan mana yang gagal dipenuhinya, karena catatan itulah yang membuat pilihan dapat ditinjau kemudian.

Penyeimbang beban di depan dua VM peralatan bukan ketersediaan tinggi dengan sendirinya. Ia menyediakan front end, bukan status terowongan yang tersinkron, dan failover yang menjatuhkan setiap sesi adalah pilihan desain yang harus diambil seseorang dengan sengaja. Tanyakan kepada vendor peralatan apa pola HA yang didukung dan apakah cocok dengan ketersediaan yang dijanjikan ke situs. Uji failover sebelum situs itu bergantung padanya, dan perlakukan setiap sesi yang hilang sebagai temuan, bukan kejutan.

Ketika persyaratannya benar-benar sederhana — satu situs, satu prefiks, tanpa tumpang tindih — layanan terkelola biasanya menang pada biaya operasional. Ketika penerjemahan dan perutean dinamis sama-sama berperan, jalur peralatan mungkin satu-satunya yang sesuai, dan itu alasan merencanakan migrasi lebih panjang alih-alih mempertahankan VM yang tidak didukung.

Jika VM RRAS sudah berjalan

Penemuan bukan alasan untuk menghapusnya. Rencanakan perubahan di sekitar dependensi yang dikumpulkan VM itu: rute yang diandalkan subnet lain, aturan NAT yang menyembunyikan alamat sumber, dan apa pun yang telah dipelajari pemantauan untuk diharapkan dari alamatnya. Pertahankan rute yang diperlukan dan jalur pemulihan yang teruji saat target yang didukung dirancang dan divalidasi di sampingnya.

Pertahankan daya dukung dan diagnosis teknis sebagai temuan terpisah sepanjang waktu. Penataan yang tidak didukung juga bisa memiliki kesalahan perutean biasa, dan memperbaiki kesalahan itu tidak mengubah status dukungannya. Kedua pernyataan itu masuk dalam laporan, dan tidak satu pun membatalkan yang lain.

Tutup panduan dengan mencatat kutipan dukungan, daftar persyaratan, pengganti yang dipilih, dan urutan peralihan. Keempat butir itulah yang pertama kali akan diminta auditor atau anggota tim baru.