RRAS Azure VM nepalaikomas: patikrinkite prieš projektuodami

Atidarote portalą, įdiegiate Windows Server 2022 į potinklį, ir Remote Access vaidmuo įdiegiamas be problemų. Ši seka įrodo, kad diegėjas veikia, o ne kad Microsoft palaiko šią konfigūraciją. Paskelbtos serverinės programinės įrangos palaikymo gairės Azure virtualioms mašinoms įtraukia RRAS į Windows Server funkcijas, kurios nepalaikomos Azure VM, ir tai architektūros sprendimas, o ne trikčių šalinimo detalė. Tunelis, kuris pakyla, neperkelia diegimo į palaikymo ribą.

Toliau pateiktas vadovas prasideda palaikymo puslapyje, o tada pereina prie reikalavimų ir pakeitimo variantų.

Pradėkite nuo palaikymo puslapio, o ne laboratorijoje

Prieš ką nors matuodami perskaitykite Azure VM palaikymo gaires. Jos atskiria palaikomus produktus, vaidmenis ir funkcijas, o ne traktuoja Windows Server kaip vieną neskirstomą bloką. Atkreipkite dėmesį, į kurią eilutę iš tikrųjų patenka jūsų numatytas darbo krūvis, nes du konsolėje susiję atrodantys komponentai gali būti skirtingose eilutėse.

Įrašykite citatą į projektavimo dokumentą, kol puslapis atidarytas. Palaikymo būsena yra faktas su šaltiniu, o projektavimo apžvalgą, kuri negali jo cituoti, nugalės tas, kas turi demonstraciją.

Atskirkite OS palaikymą nuo vaidmenų ir funkcijų palaikymo

Tos pačios gairės įtraukia Network Policy and Access Services į palaikomus vaidmenis, o RRAS atskirai nurodo kaip nepalaikomą. Šie du įrašai apibūdina skirtingus dalykus, ir jų sujungimas į „nuotolinė prieiga palaikoma“ yra būdas, kuriuo projektas patvirtinamas remiantis klaidingu perskaitymu. Tai, kad operacinė sistema palaikoma, nieko nesako apie funkciją, turinčią savo eilutę.

Apribojimas taip pat siauresnis, nei kartais cituojama. Jis susijęs su ta funkcija, veikiančia Azure VM viduje; tai nereiškia, kad privatus tinklas negali prisijungti prie Azure, ir nesako, kad RRAS nepalaikomas visur. Senesnė laboratorija, kuri teisingai perduoda paketus, yra įrodymas apie paketus, o ne apie palaikymo pareiškimą.

Laikykite šiuos du klausimus atskirai visą likusį projektą: ar tai veikia, ir ar tai palaikoma. Jums reikės skirtingų atsakymų ir kartais skirtingų atsakingų asmenų kiekvienam.

Užrašykite, ką projektas iš tikrųjų turi daryti

Prieš pasirinkdami pakaitalą, paverskite svetainių sąrašą reikalavimais, pagal kuriuos produktą galima matuoti:

• Tunelio protokolai, kuriuos filialų įrenginiai jau naudoja, ir ar kuriai nors svetainei reikia dinaminio maršrutizavimo.
• Nuotoliniai prefiksai, įskaitant bet kokią persidengiančią adresų erdvę, kuriai reikia vertimo, o ne maršrutizavimo.
• Maršrutų mainai su Azure ir kas valdo kiekvieną maršrutų lentelės įrašą.
• Pralaidumas ir jungčių skaičius, kuriuos turi atlaikyti judriausia valanda.
• Perėjimo į atsarginį režimą elgsena, dėl kurios susitarė svetainių savininkai, o ne tik tai, ką galite pastatyti.

NAT yra tas punktas, kuris praleidžiamas ir tada nulemia visą projektą. Įrenginys, galintis užmegzti IPsec, vis tiek gali versti adresus kitaip nei RRAS diegimas, kurį jis pakeičia, ir tai keičia, ką filialas mato kaip šaltinio adresus ir ką įrašo jūsų žurnalai.

Nuneškite sąrašą tinklo savininkams ir patvirtinkite jį prieš bet kokį produktų svarstymą. Dviprasmiai reikalavimai kiekvieną tiekėjų palyginimą paverčia skonio ginču.

Įvertinkite pakaitalus pagal tuos reikalavimus

Azure valdomos jungiamumo paslaugos ir tiekėjų palaikomi tinklo virtualūs įrenginiai abu turi būti vertinami pagal tą patį sąrašą. Nemanymu, kad kuris nors iš jų yra tiesioginis RRAS VM atitikmuo vien todėl, kad gali užbaigti IPsec: NAT modelis ir maršrutų nuosavybė bei aukšto prieinamumo projektas nulemia, kaip jungiasi esamos svetainės ir kur grįžta jų atsakymai. Vertinkite kiekvieną kandidatą popieriuje pagal sąrašą ir užrašykite, kurių reikalavimų jis neatitinka, nes būtent ta pastaba leidžia vėliau peržiūrėti pasirinkimą.

Apkrovos balansuotojas priešais du įrenginio VM pats savaime nėra aukštas prieinamumas. Jis suteikia priekinę dalį, o ne sinchronizuotą tunelio būseną, o perėjimas, kuris numeta kiekvieną sesiją, yra projektavimo sprendimas, kurį kažkas turi priimti sąmoningai. Paklauskite įrenginio tiekėjo, koks yra palaikomas HA modelis ir ar jis atitinka svetainėms pažadėtą prieinamumą. Išbandykite perėjimą prieš tai, kai tos svetainės taps nuo jo priklausomos, ir kiekvieną prarastą sesiją traktuokite kaip radinį, o ne netikėtumą.

Kai reikalavimas tikrai paprastas — viena svetainė, vienas prefiksas, jokio persidengimo — valdoma paslauga paprastai laimi eksploatacinių išlaidų atžvilgiu. Kai vertimas ir dinaminis maršrutizavimas abu dalyvauja, įrenginio kelias gali būti vienintelis tinkamas, ir tai priežastis planuoti ilgesnę migraciją, o ne laikyti nepalaikomą VM.

Jei RRAS VM jau veikia

Aptikimas nėra priežastis jį ištrinti. Planuokite pokytį atsižvelgdami į priklausomybes, kurias tas VM sukaupė: maršrutus, kuriais remiasi kiti potinkliai, NAT taisykles, slepiančias šaltinio adresus, ir visa, ko stebėjimas išmoko tikėtis iš jo adreso. Išsaugokite reikalingus maršrutus ir išbandytą atkūrimo kelią, kol palaikomas tikslas projektuojamas ir tikrinamas šalia.

Visą laiką laikykite palaikomumą ir techninę diagnostiką atskirais radiniais. Nepalaikomas išdėstymas taip pat gali turėti įprastą maršrutizavimo klaidą, ir tos klaidos ištaisymas nekeičia jo palaikymo būsenos. Abu teiginiai priklauso ataskaitai, ir nė vienas nepanaikina kito.

Užbaikite vadovą įrašydami palaikymo citatą, reikalavimų sąrašą, pasirinktą pakaitalą ir perėjimo tvarką. Šie keturi punktai yra pirmieji, kurių paklaus auditorius arba naujas komandos narys.