RRAS na virtualnem stroju Azure ni podprt: preverite pred načrtovanjem

Odprete portal, v podomrežje namestite Windows Server 2022 in vloga Remote Access se namesti brez težav. To zaporedje dokazuje, da namestitveni program deluje, ne pa da Microsoft podpira to konfiguracijo. Objavljene smernice za podporo strežniške programske opreme za virtualne stroje Azure uvrščajo RRAS med funkcije Windows Server, ki niso podprte na virtualnih strojih Azure, in to je arhitekturna odločitev, ne podrobnost odpravljanja težav. Tunel, ki se dvigne, ne premakne uvedbe znotraj meje podpore.

Spodnji vodnik se začne na strani za podporo in nato preide k zahtevam in možnostim zamenjave.

Začnite na strani za podporo, ne v laboratoriju

Preden karkoli razsežnostno določite, preberite smernice za podporo virtualnih strojev Azure. Ločujejo podprte izdelke, vloge in funkcije, namesto da bi Windows Server obravnavale kot en nerazdeljen blok. Bodite pozorni, v katero vrstico dejansko spada predvidena delovna obremenitev, ker lahko dve komponenti, ki sta v konzoli videti povezani, stojita v različnih vrsticah.

Zapišite citat v načrtovalski dokument, dokler je stran odprta. Status podpore je dejstvo z virom, načrtovalski pregled, ki ga ne more citirati, pa bo premagal tisti, ki ima predstavitev.

Ločite podporo operacijskega sistema od podpore vlog in funkcij

Iste smernice uvrščajo Network Policy and Access Services med podprte vloge, medtem ko RRAS navajajo ločeno kot nepodprt. Ta dva vnosa opisujeta različne stvari, njuno združevanje v „oddaljeni dostop je podprt“ pa je način, kako je projekt odobren na podlagi napačnega branja. To, da je operacijski sistem podprt, ne pove ničesar o funkciji, ki ima svojo vrstico.

Omejitev je tudi ožja, kot se včasih citira. Nanaša se na to funkcijo, ki deluje znotraj virtualnega stroja Azure; ne pomeni, da se zasebno omrežje ne more povezati z Azure, in ne pravi, da RRAS ni podprt nikjer. Starejši laboratorij, ki pravilno posreduje pakete, je dokaz o paketih, ne o izjavi o podpori.

Ti dve vprašanji držite ločeni do konca projekta: ali deluje in ali je podprto. Za vsako boste potrebovali drugačne odgovore in včasih drugačne odgovorne.

Zapišite, kaj mora načrt dejansko narediti

Preden izberete zamenjavo, spremenite seznam lokacij v zahteve, po katerih je mogoče meriti izdelek:

• Tunelski protokoli, ki jih naprave v podružnicah že govorijo, in ali katera lokacija potrebuje dinamično usmerjanje.
• Oddaljeni predpone, vključno z vsakim prekrivajočim se naslovnim prostorom, ki potrebuje prevajanje, ne usmerjanje.
• Izmenjava poti z Azure in kdo je lastnik vsakega vnosa v usmerjevalni tabeli.
• Prepustnost in število povezav, ki jih mora vzdržati najbolj obremenjena ura.
• Vedenje ob preklopu, o katerem so se dogovorili lastniki lokacij, ne le tisto, ki ga lahko zgradite.

NAT je postavka, ki se preskoči in nato odloči celoten načrt. Naprava, ki lahko vzpostavi IPsec, lahko še vedno prevaja naslove drugače kot uvedba RRAS, ki jo nadomešča, in to spremeni, kaj podružnica vidi kot izvorne naslove in kaj zabeležijo vaši dnevniki.

Seznam odnesite k lastnikom omrežja in ga potrdite pred vsako razpravo o izdelkih. Dvoumne zahteve spremenijo vsako primerjavo ponudnikov v spor o preferencah.

Ocenite zamenjave glede na te zahteve

Upravljane povezovalne storitve Azure in omrežne virtualne naprave, ki jih podpirajo ponudniki, je treba ocenjevati po istem seznamu. Ne predpostavljajte, da je katera od njih neposredni ekvivalent virtualnega stroja z RRAS le zato, ker lahko zaključi IPsec: model NAT in lastništvo poti ter načrt visoke razpoložljivosti določajo, kako se povezujejo obstoječe lokacije in kam se vračajo njihovi odgovori. Vsakega kandidata ocenite na papirju po seznamu in zapišite, katerih zahtev ne izpolnjuje, saj prav ta zapisek omogoča poznejši pregled izbire.

Krmilnik porazdelitve obremenitve pred dvema virtualnima napravama sam po sebi ni visoka razpoložljivost. Zagotavlja sprednji del, ne sinhroniziranega stanja tunelov, preklop, ki spusti vsako sejo, pa je načrtovalska odločitev, ki se je mora nekdo lotiti namerno. Vprašajte ponudnika naprave, kateri vzorec HA je podprt in ali ustreza razpoložljivosti, obljubljeni lokacijam. Preizkusite preklop, preden so te lokacije od njega odvisne, in vsako izgubljeno sejo obravnavajte kot ugotovitev, ne kot presenečenje.

Kjer je zahteva res preprosta — ena lokacija, en predpona, brez prekrivanja — upravljana storitev običajno zmaga pri obratovalnih stroških. Kjer sta v igri tako prevajanje kot dinamično usmerjanje, je pot prek naprave morda edina primerna, in to je razlog za načrtovanje daljše selitve namesto ohranjanja nepodprtega virtualnega stroja.

Če virtualni stroj z RRAS že deluje

Odkritje ni razlog za njegovo brisanje. Načrtujte spremembo okoli odvisnosti, ki jih je ta virtualni stroj nabral: poti, na katere se zanašajo druga podomrežja, pravil NAT, ki skrivajo izvorne naslove, in vsega, kar se je nadzor naučil pričakovati od njegovega naslova. Ohranite potrebne poti in preizkušeno pot obnovitve, medtem ko se podprti cilj načrtuje in preverja ob njem.

Podprtost in tehnično diagnostiko ves čas držite kot ločene ugotovitve. Nepodprta ureditev ima lahko tudi običajno napako usmerjanja, odprava te napake pa ne spremeni njenega statusa podpore. Obe trditvi spadata v poročilo in nobena ne razveljavi druge.

Vodnik zaključite z zapisom citata podpore, seznama zahtev, izbrane zamenjave in vrstnega reda prehoda. Te štiri postavke so prvo, kar bo vprašal revizor ali nov član ekipe.