RRAS në një VM Azure nuk mbështetet: kontrolloni para projektimit

Hapni portalin, vendosni Windows Server 2022 në një nënrrjet dhe roli Remote Access instalohet pa probleme. Ai sekuencë provon që instaluesi funksionon, jo që Microsoft e mbështet konfigurimin. Udhëzimet e publikuara të mbështetjes për softuerin e serverit për makinat virtuale Azure e përfshijnë RRAS ndër veçoritë e Windows Server që nuk mbështeten në VM-të Azure, dhe ky është një vendim arkitekturor, jo një detaj i zgjidhjes së problemeve. Një tunel që ngrihet nuk e zhvendos vendosjen brenda kufirit të mbështetjes.

Udhëzuesi më poshtë fillon në faqen e mbështetjes dhe më pas kalon te kërkesat dhe opsionet e zëvendësimit.

Filloni në faqen e mbështetjes, jo në laborator

Lexoni udhëzimet e mbështetjes për VM-të Azure përpara se të përmasojmë ndonjë gjë. Ato i ndajnë produktet, rolet dhe veçoritë e mbështetura në vend që ta trajtojnë Windows Server si një bllok të pandarë. Vini re se në cilin rresht bie në të vërtetë ngarkesa e planifikuar, sepse dy komponentë që duken të lidhur në konsolë mund të qëndrojnë në rreshta të ndryshëm.

Shkruajeni citimin në dokumentin e projektimit ndërsa faqja është e hapur. Statusi i mbështetjes është një fakt me burim, dhe një rishikim projektimi që nuk mund ta citojë atë do të mposhtet nga ai që ka demonstrimin.

Ndani mbështetjen e OS nga mbështetja e roleve dhe veçorive

Të njëjtat udhëzime e listojnë Network Policy and Access Services ndër rolet e mbështetura, ndërsa RRAS listohet veçmas si i pambështetur. Këto dy zëra përshkruajnë gjëra të ndryshme, dhe bashkimi i tyre në „aksesi në distancë mbështetet“ është mënyra se si një projekt miratohet mbi një lexim të gabuar. Fakti që sistemi operativ mbështetet nuk thotë asgjë për një veçori që ka rreshtin e vet.

Kufizimi është gjithashtu më i ngushtë sesa citohet ndonjëherë. Ai ka të bëjë me atë veçori që funksionon brenda një VM Azure; nuk do të thotë që një rrjet privat nuk mund të lidhet me Azure, dhe nuk thotë që RRAS nuk mbështetet askund. Një laborator i vjetër që përcjell paketat saktë është provë për paketat, jo për deklaratën e mbështetjes.

Mbani këto dy pyetje të ndara për pjesën tjetër të projektit: funksionon dhe mbështetet. Do të keni nevojë për përgjigje të ndryshme dhe ndonjëherë për pronarë të ndryshëm për secilën.

Shkruani çfarë duhet të bëjë në të vërtetë projektimi

Përpara se të zgjidhni një zëvendësim, ktheni listën e vendeve në kërkesa me të cilat një produkt mund të matet:

• Protokollet e tuneleve që pajisjet e degëve tashmë flasin, dhe nëse ndonjë vend ka nevojë për rrugëtim dinamik.
• Parashtesat në distancë, duke përfshirë çdo hapësirë adresash që mbivendoset dhe kërkon përkthim, jo rrugëtim.
• Shkëmbimi i rrugëve me Azure, dhe kush zotëron çdo zë të tabelës së rrugëtimit.
• Performanca dhe numri i lidhjeve që duhet të përballojë ora më e ngarkuar.
• Sjellja e kalimit në rast dështimi për të cilën janë dakord pronarët e vendeve, jo vetëm ajo që mund të ndërtoni.

NAT është elementi që anashkalohet dhe më pas vendos të gjithë projektimin. Një pajisje që mund të vendosë IPsec mund të përkthejë adresat ndryshe nga vendosja e RRAS që zëvendëson, dhe kjo ndryshon atë që dega sheh si adresa burimore dhe çfarë regjistrojnë regjistrat tuaj.

Çojeni listën te pronarët e rrjetit dhe konfirmojeni përpara çdo diskutimi për produkte. Kërkesat e paqarta e kthejnë çdo krahasim furnitorësh në një debat preference.

Vlerësoni zëvendësimet kundrejt atyre kërkesave

Shërbimet e menaxhuara të lidhjes së Azure dhe pajisjet virtuale të rrjetit të mbështetura nga furnitorët duhet të vlerësohen të dyja kundrejt të njëjtës listë. Mos supozoni se ndonjëra prej tyre është ekuivalent i drejtpërdrejtë i një VM RRAS vetëm sepse mund të përfundojë IPsec: modeli NAT dhe pronësia e rrugëve dhe projektimi i disponueshmërisë së lartë vendosin se si lidhen vendet ekzistuese dhe ku kthehen përgjigjet e tyre. Vlerësoni çdo kandidat në letër kundrejt listës dhe shkruani cilat kërkesa nuk i plotëson, sepse pikërisht ai shënim e bën zgjedhjen të rishikueshme më vonë.

Një balancues ngarkese përpara dy VM-ve pajisje nuk është vetë disponueshmëri e lartë. Ai ofron një front-end, jo një gjendje tuneli të sinkronizuar, dhe një kalim dështimi që lëshon çdo sesion është një vendim projektimi që dikush duhet ta marrë me qëllim. Pyetni furnitorin e pajisjes cili është modeli HA i mbështetur dhe nëse përputhet me disponueshmërinë e premtuar vendeve. Testoni kalimin përpara se ato vende të varen prej tij, dhe trajtoni çdo sesion të humbur si një gjetje dhe jo si një surprizë.

Ku kërkesa është vërtet e thjeshtë — një vend, një parashtesë, pa mbivendosje — një shërbim i menaxhuar zakonisht fiton në koston operative. Ku përkthimi dhe rrugëtimi dinamik janë të dy në lojë, rruga e pajisjes mund të jetë e vetmja e përshtatshme, dhe kjo është arsye për të planifikuar një migrim më të gjatë në vend që të mbani VM-në e pambështetur.

Nëse një VM RRAS është tashmë në punë

Zbulimi nuk është arsye për ta fshirë. Planifikoni ndryshimin rreth varësive që ka grumbulluar ai VM: rrugë nga të cilat varen nënrrjeta të tjera, rregulla NAT që fshehin adresat burimore, dhe gjithçka që monitorimi ka mësuar të presë nga adresa e tij. Ruani rrugët e nevojshme dhe një rrugë rikuperimi të testuar, ndërsa objektivi i mbështetur projektohet dhe validohet pranë.

Mbani mbështetësinë dhe diagnozën teknike si gjetje të ndara gjatë gjithë kohës. Një rregullim i pambështetur mund të ketë edhe një gabim të zakonshëm rrugëtimi, dhe korrigjimi i atij gabimi nuk e ndryshon statusin e mbështetjes. Të dy pohimet i përkasin raportit, dhe asnjëri nuk e anulon tjetrin.

Mbyllni udhëzuesin duke regjistruar citimin e mbështetjes, listën e kërkesave, zëvendësimin e zgjedhur dhe rendin e kalimit. Këto katër zëra janë gjëja e parë që do të kërkojë një auditues ose një anëtar i ri i ekipit.