Ang RRAS sa isang Azure VM ay hindi sinusuportahan: suriin bago magdisenyo

Bubuksan mo ang portal, ide-deploy ang Windows Server 2022 sa isang subnet, at malinis na nai-install ang role na Remote Access. Ang pagkakasunod-sunod na iyon ay nagpapatunay na gumagana ang installer, hindi na sinusuportahan ng Microsoft ang configuration. Inililista ng nailathalang gabay sa suporta ng server software para sa Azure virtual machines ang RRAS sa mga feature ng Windows Server na hindi sinusuportahan sa Azure VM, at iyon ay desisyon sa arkitektura, hindi detalye ng pag-troubleshoot. Ang tunnel na bumabangon ay hindi naglilipat ng deployment sa loob ng hangganan ng suporta.

Ang gabay sa ibaba ay nagsisimula sa pahina ng suporta, pagkatapos ay lumalawak patungo sa mga kinakailangan at opsyon sa pagpapalit.

Magsimula sa pahina ng suporta, hindi sa lab

Basahin ang gabay sa suporta ng Azure VM bago sukatin ang anuman. Hinihiwalay nito ang mga produktong sinusuportahan, role at feature sa halip na ituring ang Windows Server bilang isang blokeng walang pagkakaiba. Pansinin kung saang hilera talaga nabibilang ang planong workload, dahil ang dalawang bahaging mukhang magkaugnay sa console ay maaaring nasa magkaibang hilera.

Isulat ang sipi sa dokumento ng disenyo habang bukas ang pahina. Ang katayuan ng suporta ay katotohanang may pinagmulan, at ang pagsusuri ng disenyo na hindi ito masipi ay matatalo ng may demo.

Ihiwalay ang suporta sa OS mula sa suporta sa role at feature

Inililista ng parehong gabay ang Network Policy and Access Services sa mga sinusuportahang role habang inililista ang RRAS nang hiwalay bilang hindi sinusuportahan. Ang dalawang entry na iyon ay naglalarawan ng magkaibang bagay, at ang pagsasama sa kanila bilang “sinusuportahan ang remote access” ay ang paraan ng pag-apruba ng proyekto batay sa maling pagbasa. Ang pagiging sinusuportahan ng operating system ay walang sinasabi tungkol sa isang feature na may sariling hilera.

Ang limitasyon ay mas makitid din kaysa sa kung minsan ay sinisipi. Tungkol ito sa feature na tumatakbo sa loob ng Azure VM; hindi ibig sabihin na hindi makakonekta ang pribadong network sa Azure, at hindi nito sinasabi na hindi sinusuportahan ang RRAS kahit saan. Ang lumang lab na nagpapasa ng mga packet nang tama ay ebidensya tungkol sa mga packet, hindi tungkol sa pahayag ng suporta.

Panatilihing hiwalay ang dalawang tanong na iyon sa natitirang proyekto: gumagana ba ito, at sinusuportahan ba ito. Kakailanganin mo ng magkaibang sagot at kung minsan magkaibang may-ari para sa bawat isa.

Isulat kung ano talaga ang dapat gawin ng disenyo

Bago pumili ng kapalit, gawing mga kinakailangang masusukat ang listahan ng site:

• Ang mga protocol ng tunnel na ginagamit na ng mga device sa sangay, at kung kailangan ng anumang site ng dynamic na routing.
• Ang malalayong prefix, kasama ang anumang magkapatong na espasyo ng address na nangangailangan ng pagsasalin kaysa routing.
• Ang pagpapalitan ng ruta sa Azure, at kung sino ang may-ari ng bawat entry sa routing table.
• Ang throughput at bilang ng koneksyon na dapat tiisin ng pinaka-abalang oras.
• Ang pag-uugali sa failover na pinagkasunduan ng mga may-ari ng site, hindi lamang ang kayang itayo.

Ang NAT ang aytem na nilalaktawan at pagkatapos ay nagpapasya sa buong disenyo. Ang device na makakapagtatag ng IPsec ay maaari pa ring magsalin ng mga address nang iba kaysa sa RRAS deployment na pinapalitan nito, at binabago nito kung ano ang nakikitang source address ng sangay at kung ano ang naitala ng iyong mga log.

Dalhin ang listahan sa mga may-ari ng network at kumpirmahin bago ang anumang talakayan sa produkto. Ang malabong kinakailangan ay ginagawang pagtatalo sa kagustuhan ang bawat paghahambing ng vendor.

Tayahin ang mga kapalit laban sa mga kinakailangang iyon

Ang mga managed connectivity service ng Azure at ang mga virtual network appliance na sinusuportahan ng vendor ay parehong kailangang bigyan ng marka laban sa parehong listahan. Huwag ipagpalagay na ang alinman sa kanila ay direktang katumbas ng RRAS VM dahil lang kayang tapusin ang IPsec: ang modelo ng NAT at pagmamay-ari ng ruta at ang disenyo ng high availability ang nagpapasya kung paano kumakonekta ang mga umiiral na site at saan bumabalik ang kanilang mga sagot. Bigyan ng marka ang bawat kandidato sa papel laban sa listahan at isulat kung aling mga kinakailangan ang nabigo nito, dahil ang tala na iyon ang nagpapasuri ng pagpili sa ibang pagkakataon.

Ang load balancer sa harap ng dalawang appliance VM ay hindi high availability sa sarili nito. Nagbibigay ito ng front end, hindi synchronized na estado ng tunnel, at ang failover na nagtatanggal ng bawat session ay desisyong pandisenyo na dapat sadyang gawin ng isang tao. Itanong sa vendor ng appliance kung ano ang sinusuportahang pattern ng HA at kung tumutugma ito sa availability na ipinangako sa mga site. Subukan ang failover bago umasa ang mga site na iyon dito, at ituring ang bawat nawalang session bilang natuklasan at hindi sorpresa.

Kung ang kinakailangan ay talagang simple — isang site, isang prefix, walang overlap — kadalasang nananalo ang managed service sa gastos sa operasyon. Kapag ang pagsasalin at dynamic na routing ay parehong nasa laro, ang daan ng appliance ay maaaring ang tanging angkop, at iyon ay dahilan para magplano ng mas mahabang migration kaysa panatilihin ang hindi sinusuportahang VM.

Kung may tumatakbong RRAS VM na

Ang pagtuklas ay hindi dahilan para burahin ito. Planuhin ang pagbabago sa paligid ng mga dependency na naipon ng VM na iyon: mga rutang umaasa ang ibang subnet, mga panuntunan ng NAT na nagtatago ng source address, at lahat ng natutunan ng monitoring na asahan mula sa address nito. Panatilihin ang mga kinakailangang ruta at nasubok na daan ng pagbawi habang ang sinusuportahang target ay idinisenyo at pinapatunayan sa tabi.

Panatilihing hiwalay na natuklasan ang supportability at teknikal na diagnosis sa lahat ng oras. Ang hindi sinusuportahang kaayusan ay maaari ding magkaroon ng ordinaryong error sa routing, at ang pagwawasto sa error na iyon ay hindi nagbabago sa katayuan ng suporta. Ang parehong pahayag ay kabilang sa ulat, at walang isa ang nagpapawalang-bisa sa isa.

Tapusin ang gabay sa pamamagitan ng pagtatala ng sipi ng suporta, listahan ng kinakailangan, napiling kapalit at pagkakasunod-sunod ng paglipat. Ang apat na aytem na iyon ang unang itatanong ng auditor o bagong miyembro ng team.