RRAS op in Azure VM wurdt net stipe: kontrolearje foar it ûntwerp
Windows Server rint yn Azure, mar de stipe-rjochtlinen fan Microsoft neame RRAS as net stipe op Azure VM's. Kontrolearje dy grins foardat jo dêr in VPN omhinne bouwe.
Jo iepenje it portaal, sette Windows Server 2022 yn in subnet en de Remote Access-rol ynstallearret sûnder problemen. Dy folchoarder bewyst dat de ynstallearder wurket, net dat Microsoft de konfiguraasje stipet. De publisearre stipe-rjochtline foar serversoftware foar Azure-firtuële masines neamt RRAS ûnder de Windows Server-funksjes dy't net stipe wurde op Azure VM's, en dat is in arsjitektuerbeslút, gjin detail fan probleemoplossing. In tunnel dy't omheech komt, ferpleatst de ymplemintaasje net binnen de stipegrins.
De trochgong hjirûnder begjint op de stipeside en wurket dêrwei nei easken en ferfangingopsjes.
Begjin op de stipeside, net yn it laboratoarium
Lês de stipe-rjochtline foar Azure VM foardat jo wat dan ek bemjitte. Se skiede stipe produkten, rollen en funksjes ynstee fan Windows Server as ien ûnferskillend blok te behanneljen. Tink derop wêr't jo bedoelde wurklêst eins ûnder falt, want twa komponinten dy't yn 'e konsole besibbe lykje, kinne yn ferskillende rigen sitte.
Skriuw de sitaten yn it ûntwerpdokumint wylst de side iepen is. Stipestatus is in feit mei in boarne, en in ûntwerpbeoardieling dy't dat net sitearje kin, wurdt troch dejinge mei de demo ûnder tafel prate.
Skied OS-stipe fan stipe fan rollen en funksjes
Deselde rjochtline neamt Network Policy and Access Services ûnder stipe rollen, wylst RRAS apart as net stipe neamd wurdt. Dy twa yngongen beskriuwe ferskillende dingen, en se gearfoegje ta „remote access wurdt stipe“ is hoe't in projekt goedkard wurdt op basis fan in ferkearde lêzing. Dat it bestjoeringssysteem stipe wurdt, seit neat oer in funksje mei in eigen rige.
De beheining is ek smeller as't se soms sitearre wurdt. It giet oer dy funksje dy't binnen in Azure VM rint; it betsjut net dat in priveenetwurk gjin ferbining mei Azure meitsje kin, en it seit net dat RRAS oeral net stipe wurdt. In âlder laboratoarium dat pakketten goed trochstjoert, is bewiis oer pakketten, net oer de stipeferklearring.
Hâld dy twa fragen foar de rest fan it projekt apart: wurket it, en wurdt it stipe. Jo sille ferskillende antwurden en soms ferskillende eigners foar elk nedich hawwe.
Skriuw op wat it ûntwerp eins dwaan moat
Foardat jo in ferfanging kieze, feroarje de list fan lokaasjes yn easken dêr't in produkt oan metten wurde kin:
- Tunnelprotokollen dy't de apparaten fan 'e filialen al sprekke, en oft in lokaasje dynamyske routing nedich hat.
- De fiere prefiksen, ynklusyf alle oerlappende adresromte dy't oersetting nedich hat ynstee fan routing.
- Routemingswikseling mei Azure, en wa't elk ynkommen fan 'e routingtabel besit.
- Trochgong en oantallen ferbiningen dy't it drokste oere hâlde moat.
- Failover-gedrach dêr't de eigners fan 'e lokaasjes oer iens binne, net allinnich dat jo bouwe kinne.
NAT is it ûnderdiel dat oerslein wurdt en dan it hiele ûntwerp beslút. In apparaat dat IPsec opbringe kin, kin adressen noch oars oersette as de RRAS-ymplemintaasje dy't it ferfangt, en dat feroaret wat it filiaal as boarneadressen sjocht en wat jo logboeken fêstlizze.
Nim de list nei de netwurkeigners en befêstigje dy foar elke produktdiskúsje. Dûbelsinnige easken feroarje elke leveransiersfergeliking yn in foarkarsdiskúsje.
Evaluearje ferfangingen tsjin dy easken
Azure syn behearderskjinsten foar ferbining en troch leveransiers stipe netwurk-firtuële apparaten moatte beide tsjin deselde list skoare. Nim net oan dat ien fan beide in direkte ekwivalint fan in RRAS VM is, allinnich om't it IPsec beëinigje kin: it NAT-model en it eigendom fan rûtes en it ûntwerp foar hege beskikberens beslute hoe't besteande lokaasjes ferbine en wêr't har antwurden weromkomme. Skoarje elke kandidaat op papier tsjin 'e list en skriuw op hokker easken it net hellet, want dat notysje makket de kar letter neisjenber.
In loadbalancer foar twa apparaat-VM's is net op himsels hege beskikberens. Hy leveret in front-end, gjin syngronisearre tunnelstatus, en in failover dy't elke sesje falle lit, is in ûntwerpkar dy't immen bewust meitsje moat. Freegje de apparaatleveransier wat it stipe HA-patroan is en oft dat oerienkomt mei de beskikberens dy't de lokaasjes tasein is. Test de failover foardat dy lokaasjes dêrfan ôfhinklik binne, en behannelje elke ferlerne sesje as in befinning, net as in ferrassing.
Wêr't de eask echt ienfâldich is — ien lokaasje, ien prefiks, gjin oerlaap — wint in behearder tsjinst meastentiids op operasjonele kosten. Wêr't oersetting en dynamyske routing beide yn it spul binne, kin it apparaatpaad de ienige passende wêze, en dat is in reden om in langere migraasje te plenjen ynstee fan de net stipe VM te hâlden.
As in RRAS VM al draait
Ûntdekking is gjin reden om it te wiskjen. Plan de feroaring om 'e ôfhinklikheden hinne dy't dy VM sammele hat: rûtes dêr't oare subnetten op fertrouwe, NAT-regels dy't boarneadressen ferbergje, en alles wat monitoring leard hat fan syn adres te ferwachtsjen. Bewarje de nedige rûtes en in testen werstelpaad wylst it stipe doel derneist ûntwurpen en falidearre wurdt.
Hâld stipberens en technyske diagnose as aparte befinningen it hiele tiid. In net stipe opstelling kin ek in gewoane routingflater hawwe, en it reparearjen fan dy flater feroaret syn stipestatus net. Beide bewearings hearre yn it rapport, en gjinien annulearret de oare.
Slút de trochgong ôf troch de stipesitaat, de easkelist, de keazen ferfanging en de omskeakeloarder fêst te lizzen. Dy fjouwer punten binne wat in auditor of in nij teamlid earst freegje sil.