RRAS pada VM Azure tidak disokong: semak sebelum reka bentuk

Anda membuka portal, menggunakan Windows Server 2022 ke dalam subnet, dan peranan Remote Access dipasang dengan bersih. Urutan itu membuktikan pemasang berfungsi, bukan bahawa Microsoft menyokong konfigurasi itu. Panduan sokongan perisian pelayan yang diterbitkan untuk mesin maya Azure menyenaraikan RRAS antara ciri Windows Server yang tidak disokong pada VM Azure, dan itu keputusan seni bina, bukan butiran penyelesaian masalah. Terowong yang naik tidak memindahkan penggunaan ke dalam sempadan sokongan.

Panduan di bawah bermula pada halaman sokongan, kemudian bergerak ke luar menuju keperluan dan pilihan penggantian.

Mulakan pada halaman sokongan, bukan di makmal

Baca panduan sokongan VM Azure sebelum anda menentukan sebarang saiz. Ia memisahkan produk, peranan dan ciri yang disokong dan bukannya menganggap Windows Server sebagai satu blok tanpa pembezaan. Perhatikan baris mana beban kerja yang anda rancang sebenarnya jatuh, kerana dua komponen yang kelihatan berkaitan dalam konsol boleh berada dalam baris berbeza.

Tulis petikan itu ke dalam dokumen reka bentuk semasa halaman terbuka. Status sokongan ialah fakta dengan sumber, dan kajian semula reka bentuk yang tidak dapat memetiknya akan dikalahkan oleh pihak yang mempunyai demo.

Pisahkan sokongan OS daripada sokongan peranan dan ciri

Panduan yang sama menyenaraikan Network Policy and Access Services antara peranan yang disokong sambil menyenaraikan RRAS secara berasingan sebagai tidak disokong. Kedua-dua entri itu menerangkan perkara berbeza, dan menggabungkannya menjadi “akses jauh disokong” ialah cara projek diluluskan berdasarkan salah baca. Sistem pengendalian yang disokong tidak berkata apa-apa tentang ciri yang mempunyai barisnya sendiri.

Batasan itu juga lebih sempit daripada yang kadang-kadang dipetik. Ia berkenaan ciri tersebut yang berjalan di dalam VM Azure; ia tidak bermakna rangkaian peribadi tidak boleh bersambung ke Azure, dan ia tidak mengatakan RRAS tidak disokong di mana-mana. Makmal lama yang memajukan paket dengan betul ialah bukti tentang paket, bukan tentang pernyataan sokongan.

Kekalkan kedua-dua soalan itu berasingan sepanjang projek: adakah ia berfungsi, dan adakah ia disokong. Anda akan memerlukan jawapan berbeza dan kadang-kadang pemilik berbeza untuk setiap satu.

Tuliskan apa yang sebenarnya perlu dilakukan oleh reka bentuk

Sebelum memilih pengganti, tukar senarai tapak menjadi keperluan yang boleh digunakan untuk mengukur produk:

• Protokol terowong yang sudah dituturkan oleh peranti cawangan, dan sama ada mana-mana tapak memerlukan penghalaan dinamik.
• Awalan jauh, termasuk mana-mana ruang alamat bertindih yang memerlukan terjemahan dan bukan penghalaan.
• Pertukaran laluan dengan Azure, dan siapa memiliki setiap entri jadual penghalaan.
• Daya pemprosesan dan bilangan sambungan yang perlu ditanggung oleh jam paling sibuk.
• Tingkah laku failover yang dipersetujui oleh pemilik tapak, bukan hanya yang anda boleh bina.

NAT ialah item yang dilangkau dan kemudian menentukan keseluruhan reka bentuk. Peranti yang boleh mewujudkan IPsec masih boleh menterjemah alamat secara berbeza daripada penggunaan RRAS yang digantikannya, dan itu mengubah apa yang dilihat oleh cawangan sebagai alamat sumber dan apa yang direkodkan oleh log anda.

Bawa senarai itu kepada pemilik rangkaian dan sahkan sebelum sebarang perbincangan produk. Keperluan yang kabur menjadikan setiap perbandingan vendor sebagai pertikaian keutamaan.

Nilai pengganti terhadap keperluan itu

Perkhidmatan kesambungan terurus Azure dan perkakas rangkaian maya yang disokong vendor kedua-duanya perlu dinilai terhadap senarai yang sama. Jangan anggap mana-mana daripadanya setara langsung dengan VM RRAS semata-mata kerana ia boleh menamatkan IPsec: model NAT dan pemilikan laluan serta reka bentuk ketersediaan tinggi menentukan cara tapak sedia ada bersambung dan ke mana balasan mereka kembali. Nilai setiap calon di atas kertas terhadap senarai itu dan tuliskan keperluan mana yang gagal dipenuhinya, kerana nota itulah yang menjadikan pilihan boleh dikaji semula kemudian.

Pengimbang beban di hadapan dua VM perkakas bukan ketersediaan tinggi dengan sendirinya. Ia menyediakan bahagian hadapan, bukan keadaan terowong yang disegerakkan, dan failover yang menjatuhkan setiap sesi ialah pilihan reka bentuk yang mesti dibuat oleh seseorang secara sedar. Tanya vendor perkakas apakah corak HA yang disokong dan sama ada ia sepadan dengan ketersediaan yang dijanjikan kepada tapak. Uji failover sebelum tapak itu bergantung padanya, dan anggap setiap sesi yang hilang sebagai penemuan dan bukan kejutan.

Apabila keperluan benar-benar mudah — satu tapak, satu awalan, tiada pertindihan — perkhidmatan terurus biasanya menang dari segi kos operasi. Apabila terjemahan dan penghalaan dinamik kedua-duanya terlibat, laluan perkakas mungkin satu-satunya yang sesuai, dan itu sebab untuk merancang penghijrahan yang lebih panjang dan bukannya menyimpan VM yang tidak disokong.

Jika VM RRAS sudah berjalan

Penemuan bukan sebab untuk memadamnya. Rancang perubahan di sekeliling kebergantungan yang dikumpulkan oleh VM itu: laluan yang diharapkan oleh subnet lain, peraturan NAT yang menyembunyikan alamat sumber, dan apa sahaja yang telah dipelajari oleh pemantauan untuk dijangka daripada alamatnya. Kekalkan laluan yang diperlukan dan laluan pemulihan yang diuji semasa sasaran yang disokong direka dan disahkan di sebelahnya.

Kekalkan kebolehsokongan dan diagnosis teknikal sebagai penemuan berasingan sepanjang masa. Susunan yang tidak disokong juga boleh mempunyai ralat penghalaan biasa, dan membetulkan ralat itu tidak mengubah status sokongannya. Kedua-dua kenyataan itu tergolong dalam laporan, dan tidak satu pun membatalkan yang lain.

Tutup panduan dengan merekodkan petikan sokongan, senarai keperluan, pengganti yang dipilih dan urutan peralihan. Empat perkara itulah yang pertama kali akan diminta oleh juruaudit atau ahli pasukan baharu.