RRAS sur Azure VM ne estas subtenata: kontrolu antaŭ la dezajno

Vi malfermas la portalon, deplojas Windows Server 2022 en subreton, kaj la rolo Remote Access instaliĝas senprobleme. Tiu sinsekvo pruvas, ke la instalilo funkcias, ne ke Microsoft subtenas la agordon. La publikigitaj subtenaj gvidlinioj pri servila programaro por Azure virtualaj maŝinoj listigas RRAS inter la trajtoj de Windows Server, kiuj ne estas subtenataj sur Azure VM-oj, kaj tio estas arkitektura decido, ne detalo de problemtraktado. Tunelo, kiu leviĝas, ne movas la deplojon en la subtenan limon.

La sekva travojaĝo komenciĝas sur la subtena paĝo, poste etendiĝas al postuloj kaj anstataŭaj opcioj.

Komencu sur la subtena paĝo, ne en la laboratorio

Legu la subtenan gvidlinion pri Azure VM antaŭ ol mezuri ion ajn. Ĝi apartigas subtenatajn produktojn, rolojn kaj trajtojn anstataŭ trakti Windows Server kiel unu nediferencan blokon. Rimarku, sub kiun vicon via celata laborŝarĝo efektive falas, ĉar du komponantoj, kiuj en la konzolo aspektas rilataj, povas sidi en malsamaj vicoj.

Skribu la citaĵon en la dezajnan dokumenton dum la paĝo estas malfermita. Subtena stato estas fakto kun fonto, kaj dezajna revizio, kiu ne povas citi ĝin, estos malkonstruita de tiu, kiu havas la demon.

Apartigu OS-subtenon de subteno de roloj kaj trajtoj

La samaj gvidlinioj listigas Network Policy and Access Services inter subtenataj roloj, dum ili listigas RRAS aparte kiel nesubtenatan. Tiuj du enskriboj priskribas malsamajn aferojn, kaj kunfandi ilin en „malproksima alirado estas subtenata“ estas kiel projekto aprobiĝas sur mislego. Tio, ke la operaciumo estas subtenata, diras nenion pri trajto, kiu havas sian propran vicon.

La limigo ankaŭ estas pli mallarĝa ol oni foje citas ĝin. Ĝi koncernas tiun trajton funkciantan ene de Azure VM; ĝi ne signifas, ke privata reto ne povas konektiĝi al Azure, kaj ĝi ne diras, ke RRAS estas nesubtenata ĉie. Pli malnova laboratorio, kiu ĝuste plusendas pakaĵojn, estas pruvo pri pakaĵoj, ne pri la subtena deklaro.

Tenu tiujn du demandojn apartaj por la resto de la projekto: ĉu ĝi funkcias, kaj ĉu ĝi estas subtenata. Vi bezonos malsamajn respondojn kaj foje malsamajn posedantojn por ĉiu.

Skribu, kion la dezajno efektive devas fari

Antaŭ ol elekti anstataŭon, transformu la liston de ejoj en postulojn, laŭ kiuj produkto povas esti mezurita:

• La tunelaj protokoloj, kiujn la aparatoj de la filioj jam parolas, kaj ĉu iu ejo bezonas dinamikan routadon.
• La malproksimaj prefiksoj, inkluzive de ajna interkovranta adresspaco, kiu bezonas tradukon anstataŭ routadon.
• La interŝanĝo de routoj kun Azure, kaj kiu posedas ĉiun enskribon en la routa tabelo.
• La trairo kaj nombro da konektoj, kiujn la plej okupata horo devas elteni.
• La malsukcesa konduto, pri kiu interkonsentis la posedantoj de la ejoj, ne nur tiu, kiun vi povas konstrui.

NAT estas la ero, kiu estas preterlasata kaj poste decidas la tutan dezajnon. Aparato, kiu povas starigi IPsec, ankoraŭ povas traduki adresojn alimaniere ol la RRAS-deplojo, kiun ĝi anstataŭas, kio ŝanĝas, kion la filio vidas kiel fontajn adresojn kaj kion viaj protokoloj registras.

Portu la liston al la retaj posedantoj kaj konfirmu ĝin antaŭ iu ajn produkta diskuto. Malklaraj postuloj transformas ĉiun vendistan komparon en debaton pri preferoj.

Taksu anstataŭojn laŭ tiuj postuloj

La administrataj konektecservoj de Azure kaj la vendiste subtenataj retaj virtualaj aparatoj ambaŭ devas esti taksataj laŭ la sama listo. Ne supozu, ke iu el ili estas rekta ekvivalento de RRAS VM nur ĉar ĝi povas fini IPsec: la NAT-modelo kaj la posedo de routoj kaj la dezajno de alta disponebleco decidas, kiel konektiĝas ekzistantaj ejoj kaj kien revenas iliaj respondoj. Taksu ĉiun kandidaton surpapere laŭ la listo kaj skribu, kiujn postulojn ĝi malsukcesas, ĉar tiu noto igas la elekton poste revidebla.

Ŝarĝbalancilo antaŭ du aparataj VM-oj ne estas alta disponebleco per si mem. Ĝi provizas frontan finaĵon, ne sinkronigitan tunelan staton, kaj malsukceso, kiu faligas ĉiun seancon, estas dezajna elekto, kiun iu devas fari intence. Demandu la aparatan vendiston, kiu estas la subtenata HA-ŝablono kaj ĉu ĝi kongruas kun la disponebleco promesita al la ejoj. Testu la malsukceson antaŭ ol tiuj ejoj dependos de ĝi, kaj traktu ĉiun perditan seancon kiel konstaton, ne kiel surprizon.

Kie la postulo estas vere simpla — unu ejo, unu prefikso, neniu interkovro — administrata servo kutime gajnas laŭ funkcia kosto. Kie tradukado kaj dinamika routado ambaŭ ludas, la aparata vojo povas esti la sola taŭga, kaj tio estas kialo plani pli longan migradon anstataŭ konservi la nesubtenatan VM.

Se RRAS VM jam funkcias

Malkovro ne estas kialo por forigi ĝin. Planu la ŝanĝon ĉirkaŭ la dependecoj, kiujn tiu VM amasigis: routoj, kiujn aliaj subretoj fidas, NAT-reguloj, kiuj kaŝas fontajn adresojn, kaj ĉio, kion monitorado lernis atendi de ĝia adreso. Konservu la necesajn routojn kaj testitan restaŭran vojon dum la subtenata celo estas dezajnita kaj validigita flanke.

Tenu subteneblecon kaj teknikan diagnozon kiel apartajn konkludojn la tutan tempon. Nesubtenata aranĝo ankaŭ povas havi ordinaran routan eraron, kaj korekti tiun eraron ne ŝanĝas ĝian subtenan staton. Ambaŭ asertoj apartenas al la raporto, kaj neniu nuligas la alian.

Fermu la travojaĝon registrante la subtenan citaĵon, la postulan liston, la elektitan anstataŭon kaj la transiran ordon. Tiuj kvar eroj estas tio, pri kio revizoro aŭ nova teamano unue demandos.