RRAS na Azure VM-u nije podržan: provjerite prije projektovanja

Otvorite portal, implementirate Windows Server 2022 u podmrežu i uloga Remote Access se čisto instalira. Taj slijed dokazuje da instalater radi, a ne da Microsoft podržava tu konfiguraciju. Objavljene smjernice za podršku serverskog softvera za Azure virtualne mašine navode RRAS među Windows Server funkcijama koje nisu podržane na Azure VM-ovima, i to je arhitektonska odluka, a ne detalj za rješavanje problema. Tunel koji se podigne ne pomjera implementaciju unutar granice podrške.

Pregled ispod počinje na stranici za podršku, a zatim se širi prema zahtjevima i opcijama zamjene.

Počnite na stranici za podršku, a ne u laboratoriji

Pročitajte smjernice za podršku Azure VM-a prije nego što odredite bilo kakve veličine. One razdvajaju podržane proizvode, uloge i funkcije umjesto da Windows Server tretiraju kao jedan nediferencirani blok. Obratite pažnju pod koji red zapravo pada vaše planirano opterećenje, jer dvije komponente koje u konzoli izgledaju povezano mogu stajati u različitim redovima.

Upišite citat u projektni dokument dok je stranica otvorena. Status podrške je činjenica s izvorom, a projektni pregled koji je ne može citirati bit će nadglasan od strane onoga koji ima demo.

Razdvojite podršku OS-a od podrške uloga i funkcija

Iste smjernice navode Network Policy and Access Services među podržanim ulogama, dok RRAS odvojeno navode kao nepodržan. Ta dva unosa opisuju različite stvari, a njihovo spajanje u „udaljeni pristup je podržan“ način je na koji projekt bude odobren na osnovu pogrešnog čitanja. To što je operativni sistem podržan ne govori ništa o funkciji koja ima svoj red.

Ograničenje je i uže nego što se ponekad citira. Ono se odnosi na tu funkciju koja radi unutar Azure VM-a; ne znači da se privatna mreža ne može povezati s Azureom i ne kaže da RRAS nije podržan svuda. Starija laboratorija koja ispravno prosljeđuje pakete dokaz je o paketima, a ne o izjavi o podršci.

Držite ta dva pitanja odvojenima do kraja projekta: radi li i je li podržano. Trebat će vam različiti odgovori, a ponekad i različiti vlasnici za svako.

Zapišite šta dizajn zaista mora raditi

Prije nego što odaberete zamjenu, pretvorite listu lokacija u zahtjeve prema kojima se proizvod može mjeriti:

• Tunelski protokoli koje uređaji u poslovnicama već govore i treba li neka lokacija dinamičko rutiranje.
• Udaljeni prefiksi, uključujući svaki preklapajući adresni prostor koji treba prevođenje, a ne rutiranje.
• Razmjena ruta s Azureom i ko posjeduje svaki unos u tabeli ruta.
• Propusnost i broj veza koje najprometniji sat mora izdržati.
• Ponašanje pri prebacivanju s kojim su se složili vlasnici lokacija, a ne samo ono što vi možete izgraditi.

NAT je stavka koja se preskoči, a zatim odluči cijeli dizajn. Uređaj koji može uspostaviti IPsec i dalje može prevoditi adrese drugačije od RRAS implementacije koju zamjenjuje, što mijenja šta poslovnica vidi kao izvorne adrese i šta vaši zapisi bilježe.

Odnesite listu mrežnim vlasnicima i potvrdite je prije bilo kakve rasprave o proizvodima. Dvosmisleni zahtjevi svako poređenje dobavljača pretvaraju u raspravu o preferencijama.

Procijenite zamjene prema tim zahtjevima

Azureove upravljane usluge povezivanja i mrežni virtualni uređaji koje podržava dobavljač moraju se ocjenjivati prema istoj listi. Ne pretpostavljajte da je bilo šta od toga direktni ekvivalent RRAS VM-u samo zato što može završiti IPsec: NAT model i vlasništvo nad rutama i dizajn visoke dostupnosti odlučuju kako se postojeće lokacije povezuju i kuda se vraćaju njihovi odgovori. Ocijenite svakog kandidata na papiru prema listi i zapišite koje zahtjeve ne ispunjava, jer taj zapis čini izbor kasnije provjerljivim.

Balanser opterećenja ispred dva VM uređaja nije sam po sebi visoka dostupnost. On daje front end, a ne sinhronizovano stanje tunela, a prebacivanje koje ispusti svaku sesiju je dizajnerska odluka koju neko mora donijeti namjerno. Pitajte dobavljača uređaja koji je podržani HA obrazac i odgovara li dostupnosti koja je obećana lokacijama. Testirajte prebacivanje prije nego što te lokacije zavise od njega i tretirajte svaku izgubljenu sesiju kao nalaz, a ne kao iznenađenje.

Gdje je zahtjev zaista jednostavan — jedna lokacija, jedan prefiks, bez preklapanja — upravljana usluga obično pobjeđuje po operativnom trošku. Gdje su i prevođenje i dinamičko rutiranje u igri, put preko uređaja može biti jedini prikladan, i to je razlog da planirate dužu migraciju umjesto da zadržite nepodržani VM.

Ako RRAS VM već radi

Otkriće nije razlog da ga izbrišete. Planirajte promjenu oko zavisnosti koje je taj VM skupio: ruta na koje se oslanjaju druge podmreže, NAT pravila koja skrivaju izvorne adrese i svega što je monitoring naučio očekivati od njegove adrese. Sačuvajte potrebne rute i testirani put oporavka dok se podržani cilj projektuje i validira uporedo.

Držite podrživost i tehničku dijagnostiku kao odvojene nalaze sve vrijeme. Nepodržan raspored može imati i običnu grešku rutiranja, a ispravljanje te greške ne mijenja njegov status podrške. Obje tvrdnje pripadaju izvještaju i nijedna ne poništava drugu.

Zatvorite pregled tako što ćete zabilježiti citat o podršci, listu zahtjeva, odabranu zamjenu i redoslijed prelaska. Ta četiri elementa su prvo što će revizor ili novi član tima tražiti.