RRAS Azure'i VM-il ei ole toetatud: kontrollige enne projekteerimist

Avate portaali, juurutate Windows Server 2022 alavõrku ja Remote Accessi roll paigaldub puhtalt. See järjestus tõestab, et paigaldaja töötab, mitte et Microsoft seda konfiguratsiooni toetab. Avaldatud serveritarkvara toe juhised Azure'i virtuaalmasinate jaoks loetlevad RRAS-i Windows Serveri funktsioonide hulgas, mida Azure'i VM-idel ei toetata, ja see on arhitektuurne otsus, mitte tõrkeotsingu detail. Tunnel, mis üles tuleb, ei liiguta juurutust toe piiri sisse.

Allolev ülevaade algab toe leheküljelt ja liigub sealt väljapoole nõuete ja asendusvõimaluste juurde.

Alustage toe leheküljelt, mitte laborist

Lugege Azure'i VM-i toe juhiseid enne, kui midagi mõõtmete poolest planeerite. Need eristavad toetatud tooteid, rolle ja funktsioone, selle asemel et käsitleda Windows Serverit ühe eristamata plokina. Pange tähele, millise rea alla teie kavandatud töökoormus tegelikult kuulub, sest kaks komponenti, mis konsoolis seotud paistavad, võivad olla eri ridadel.

Kirjutage viide projekteerimisdokumenti, kuni lehekülg on avatud. Toestaatus on fakt, millel on allikas, ja projekteerimisülevaatuse, mis ei suuda seda tsiteerida, vaidlustab see, kellel on demo.

Eraldage operatsioonisüsteemi tugi rollide ja funktsioonide toest

Samad juhised loetlevad Network Policy and Access Servicesi toetatud rollide hulgas, samas kui RRAS on eraldi loetletud toetamata. Need kaks kirjet kirjeldavad eri asju ja nende ühendamine väljendiks „kaugjuurdepääs on toetatud“ on viis, kuidas projekt saab vale lugemise põhjal heakskiidu. See, et operatsioonisüsteem on toetatud, ei ütle midagi funktsiooni kohta, millel on oma rida.

Piirang on ka kitsam, kui seda mõnikord tsiteeritakse. See puudutab seda funktsiooni Azure'i VM-i sees töötamisel; see ei tähenda, et privaatvõrk ei saa Azure'iga ühenduda, ega ütle, et RRAS pole kõikjal toetatud. Vanem labor, mis edastab pakette õigesti, on tõend pakettide kohta, mitte toeavalduse kohta.

Hoidke need kaks küsimust ülejäänud projekti jooksul lahus: kas see töötab ja kas see on toetatud. Vajate mõlemale erinevaid vastuseid ja mõnikord erinevaid omanikke.

Kirjutage üles, mida projekt tegelikult tegema peab

Enne asenduse valimist muutke saidi nimekiri nõueteks, mille vastu toodet saab mõõta:

• Tunneliprotokollid, mida harukontorite seadmed juba räägivad, ja kas mõni sait vajab dünaamilist marsruutimist.
• Kaugprefiksid, sealhulgas igasugune kattuv aadressiruum, mis vajab tõlkimist, mitte marsruutimist.
• Marsruutide vahetamine Azure'iga ja see, kellele kuulub iga marsruutimistabeli kirje.
• Läbilaskevõime ja ühenduste arv, mida kõige tihedam tund peab vastu pidama.
• Tõrkevõttekäitumine, millega saidiomanikud on nõustunud, mitte ainult see, mida teie suudate ehitada.

NAT on üksus, mis jäetakse vahele ja otsustab seejärel kogu projekti. Seade, mis suudab IPsec-i luua, võib siiski aadresse tõlkida teisiti kui RRAS-i juurutus, mille see asendab, ja see muudab, mida haru näeb lähteaadressidena ja mida teie logid salvestavad.

Viige nimekiri võrguomanike juurde ja kinnitage see enne igasugust toote arutelu. Ebamäärased nõuded muudavad iga tarnijate võrdluse eelistuste vaidluseks.

Hinnake asendusi nende nõuete vastu

Azure'i hallatavad ühenduvusteenused ja tarnijate toetatud võrgu virtuaalseadmed tuleb mõlemad hinnata sama nimekirja vastu. Ärge eeldage, et kumbki on RRAS-i VM-i otsene ekvivalent ainult seetõttu, et see suudab IPsec-i lõpetada: NAT-i mudel ja marsruutide omand ning kõrge käideldavuse disain otsustavad, kuidas olemasolevad saidid ühenduvad ja kuhu nende vastused tagasi jõuavad. Hinnake iga kandidaati paberil nimekirja vastu ja kirjutage üles, millised nõuded see ebaõnnestub, sest just see märkus teeb valiku hiljem ülevaatatavaks.

Koormusjaotur kahe seadme-VM-i ees ei ole iseenesest kõrge käideldavus. See pakub esiosa, mitte sünkroonitud tunneliseisundit, ja tõrkevõte, mis viskab maha iga sessiooni, on disainiotsus, mille keegi peab meelega tegema. Küsige seadme tarnijalt, milline on toetatud HA-muster ja kas see vastab saidile lubatud käideldavusele. Testige tõrkevõtet enne, kui need saidid sellest sõltuvad, ja käsitlege iga kaotatud sessiooni leiduna, mitte üllatusena.

Kui nõue on tõesti lihtne — üks sait, üks prefiks, kattuvust pole — võidab hallatav teenus tavaliselt operatiivkulude poolest. Kui tõlkimine ja dünaamiline marsruutimine on mõlemad mängus, võib seadme tee olla ainus sobiv, ja see on põhjus planeerida pikemat migratsiooni, selle asemel et hoida toetamata VM-i.

Kui RRAS-i VM juba töötab

Avastamine ei ole põhjus seda kustutada. Planeerige muudatus sõltuvuste ümber, mille see VM on kogunud: marsruudid, millele teised alavõrgud toetuvad, NAT-reeglid, mis peidavad lähteaadresse, ja kõik, mida monitooring on õppinud selle aadressilt ootama. Säilitage vajalikud marsruudid ja testitud taastamistee, samal ajal kui toetatud sihtmärk projekteeritakse ja valideeritakse kõrval.

Hoidke toetatavus ja tehniline diagnoos kogu aeg eraldi leidudena. Toetamata paigutusel võib olla ka tavaline marsruutimisviga, ja selle vea parandamine ei muuda selle toeolekut. Mõlemad väited kuuluvad aruandesse ja kumbki ei tühista teist.

Lõpetage ülevaade, registreerides toe viite, nõuete nimekirja, valitud asenduse ja ülemineku järjekorra. Need neli üksust on esimene, mida audiitor või uus meeskonnaliige küsib.