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

Otvorite portal, implementirate Windows Server 2022 u podmrežu i uloga Remote Access instalira se bez problema. Taj slijed dokazuje da instalacijski program radi, a ne da Microsoft podržava tu konfiguraciju. Objavljene smjernice za podršku poslužiteljskog softvera za Azure virtualne strojeve navode RRAS među Windows Server značajkama koje nisu podržane na Azure VM-ovima, a to je arhitektonska odluka, a ne pojedinost otklanjanja poteškoća. Tunel koji se podigne ne pomiče implementaciju unutar granice podrške.

Pregled u nastavku počinje na stranici podrške, a zatim se širi prema zahtjevima i mogućnostima zamjene.

Počnite na stranici podrške, a ne u laboratoriju

Pročitajte smjernice za podršku Azure VM-a prije nego što odredite ikakve veličine. One razdvajaju podržane proizvode, uloge i značajke umjesto da Windows Server tretiraju kao jedan nerazgraničen blok. Obratite pozornost na to u koji redak zapravo spada vaše planirano radno opterećenje, jer dvije komponente koje u konzoli izgledaju povezano mogu stajati u različitim retcima.

Upišite citat u projektni dokument dok je stranica otvorena. Status podrške činjenica je 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 značajki

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 se projekt odobrava na temelju pogrešnog čitanja. To što je operacijski sustav podržan ne govori ništa o značajki koja ima svoj redak.

Ograničenje je i uže nego što se ponekad citira. Ono se odnosi na tu značajku 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 svugdje. Stariji laboratorij koji 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 što dizajn zapravo mora raditi

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

• Tunelski protokoli koje uređaji u podružnicama već govore i treba li neka lokacija dinamičko usmjeravanje.
• Udaljeni prefiksi, uključujući svaki preklapajući adresni prostor koji treba prevođenje, a ne usmjeravanje.
• Razmjena ruta s Azureom i tko posjeduje svaki unos u tablici usmjeravanja.
• 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 što podružnica vidi kao izvorne adrese i što vaši zapisi bilježe.

Odnesite popis mrežnim vlasnicima i potvrdite ga prije bilo kakve rasprave o proizvodima. Dvosmisleni zahtjevi svaku usporedbu dobavljača pretvaraju u raspravu o preferencijama.

Procijenite zamjene prema tim zahtjevima

Azureove upravljane usluge povezivanja i mrežni virtualni uređaji koje podržavaju dobavljači moraju se oboje ocjenjivati prema istom popisu. Ne pretpostavljajte da je bilo što od toga izravni 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 kamo se vraćaju njihovi odgovori. Ocijenite svakog kandidata na papiru prema popisu 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 sinkronizirano stanje tunela, a prebacivanje koje ispusti svaku sesiju dizajnerska je odluka koju netko 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 ovise o njemu i tretirajte svaku izgubljenu sesiju kao nalaz, a ne kao iznenađenje.

Gdje je zahtjev doista 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 usmjeravanje 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 ovisnosti 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 projektira i validira usporedo.

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

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