RRAS-ը Azure VM-ում չի աջակցվում. ստուգեք նախագծից առաջ

Դուք բացում եք պորտալը, տեղակայում Windows Server 2022-ը ենթացանցում, և Remote Access դերը տեղադրվում է առանց խնդիրների։ Այդ հաջորդականությունը ապացուցում է, որ տեղադրիչը աշխատում է, ոչ թե որ Microsoft-ը աջակցում է այդ կարգավորումը։ Azure վիրտուալ մեքենաների համար հրապարակված սերվերային ծրագրային ապահովման աջակցության ուղեցույցը RRAS-ը ներառում է Windows Server-ի այն հատկությունների շարքում, որոնք չեն աջակցվում Azure VM-ներում, և դա ճարտարապետական որոշում է, ոչ թե անսարքությունների վերացման մանրամասնություն։ Բարձրացող թունելը տեղակայումը չի տեղափոխում աջակցության սահմանի ներս։

Ստորև բերված ուղեցույցը սկսվում է աջակցության էջից, ապա անցնում պահանջներին և փոխարինման տարբերակներին։

Սկսեք աջակցության էջից, ոչ լաբորատորիայից

Նախքան որևէ չափորոշում կատարելը կարդացեք Azure VM-ի աջակցության ուղեցույցը։ Այն առանձնացնում է աջակցվող արտադրանքները, դերերը և հատկությունները՝ Windows Server-ը որպես մեկ չտարբերակված բլոկ դիտարկելու փոխարեն։ Ուշադրություն դարձրեք, թե ձեր նախատեսված աշխատանքային բեռը իրականում որ տողի տակ է ընկնում, որովհետև կոնսոլում կապված թվացող երկու բաղադրիչ կարող են տարբեր տողերում լինել։

Գրեք մեջբերումը նախագծային փաստաթղթում, քանի դեռ էջը բաց է։ Աջակցության կարգավիճակը աղբյուր ունեցող փաստ է, և նախագծային վերանայումը, որը չի կարող մեջբերել այն, կպարտվի նրան, ով ունի ցուցադրությունը։

Տարանջատեք ՕՀ-ի աջակցությունը դերերի և հատկությունների աջակցությունից

Նույն ուղեցույցը Network Policy and Access Services-ը ներառում է աջակցվող դերերի շարքում, մինչդեռ RRAS-ը առանձին նշում է որպես չաջակցվող։ Այդ երկու գրառումները տարբեր բաներ են նկարագրում, և դրանք «հեռավոր մուտքը աջակցվում է» ձևով միավորելը հենց այն ճանապարհն է, որով նախագիծը հաստատվում է սխալ ընթերցման հիման վրա։ Օպերացիոն համակարգի աջակցվելը ոչինչ չի ասում սեփական տող ունեցող հատկության մասին։

Սահմանափակումը նաև ավելի նեղ է, քան երբեմն մեջբերվում է։ Այն վերաբերում է այն հատկությանը, որը աշխատում է Azure VM-ի ներսում՝ չի նշանակում, որ մասնավոր ցանցը չի կարող միանալ Azure-ին, և չի ասում, որ RRAS-ը ամենուր չի աջակցվում։ Հին լաբորատորիան, որը փաթեթները ճիշտ է փոխանցում, ապացույց է փաթեթների մասին, ոչ թե աջակցության հայտարարության։

Այս երկու հարցերը առանձին պահեք նախագծի մնացած մասի ընթացքում՝ աշխատում է արդյոք, և աջակցվու՞մ է արդյոք։ Ձեզ պետք կգան տարբեր պատասխաններ և երբեմն տարբեր պատասխանատուներ յուրաքանչյուրի համար։

Գրեք, թե նախագիծն իրականում ինչ պետք է անի

Նախքան փոխարինող ընտրելը՝ տեղանքների ցանկը վերածեք պահանջների, որոնցով կարելի է չափել արտադրանքը:

• Թունելային արձանագրությունները, որոնք մասնաճյուղերի սարքերն արդեն խոսում են, և արդյոք որևէ տեղանքի պետք է դինամիկ երթուղավորում։
• Հեռավոր նախածանցները, ներառյալ ցանկացած համընկնող հասցեային տարածություն, որը պահանջում է թարգմանություն, ոչ թե երթուղավորում։
• Երթուղիների փոխանակումը Azure-ի հետ, և թե ով է տիրապետում երթուղային աղյուսակի յուրաքանչյուր գրառմանը։
• Թողունակությունը և կապերի քանակը, որոնք ամենազբաղված ժամը պետք է դիմանա։
• Անհաջողության անցման այն վարքը, որին համաձայնել են տեղանքների սեփականատերերը, ոչ միայն այն, ինչ դուք կարող եք կառուցել։

NAT-ը այն կետն է, որը բաց են թողնում, և հետո այն որոշում է ողջ նախագիծը։ IPsec հաստատել կարող սարքը դեռ կարող է հասցեները թարգմանել այլ կերպ, քան այն RRAS տեղակայումը, որը նա փոխարինում է, և դա փոխում է, թե մասնաճյուղն ինչ է տեսնում որպես աղբյուրի հասցեներ, և ինչ են գրանցում ձեր մատյանները։

Ցանկը տարեք ցանցի սեփականատերերի մոտ և հաստատեք այն ցանկացած ապրանքային քննարկումից առաջ։ Անորոշ պահանջները յուրաքանչյուր մատակարարի համեմատությունը վերածում են նախընտրությունների վեճի։

Գնահատեք փոխարինումները այդ պահանջների համեմատ

Azure-ի կառավարվող կապակցման ծառայությունները և մատակարարների կողմից աջակցվող ցանցային վիրտուալ սարքերը երկուսն էլ պետք է գնահատվեն նույն ցանկով։ Մի ենթադրեք, որ դրանցից որևէ մեկը RRAS VM-ի ուղղակի համարժեքն է միայն այն պատճառով, որ կարող է ավարտել IPsec-ը՝ NAT մոդելը և երթուղիների պատկանելությունը և բարձր հասանելիության նախագիծը որոշում են, թե ինչպես են միանում գոյություն ունեցող տեղանքները և ուր են վերադառնում նրանց պատասխանները։ Գնահատեք յուրաքանչյուր թեկնածու թղթի վրա՝ ըստ ցանկի, և գրեք, թե որ պահանջներին նա չի բավարարում, որովհետև հենց այդ նշումն է ընտրությունը դարձնում հետագայում վերանայելի։

Երկու սարքային VM-ի առջև գտնվող բեռնվածքի բալանսավորողը ինքնին բարձր հասանելիություն չէ։ Այն տալիս է ճակատային մաս, ոչ թե համաժամեցված թունելի վիճակ, և յուրաքանչյուր սեսիա գցող անցումը նախագծային որոշում է, որը ինչ-որ մեկը պետք է դիտավորյալ կայացնի։ Հարցրեք սարքի մատակարարին, թե որն է աջակցվող HA ձևանմուշը և արդյոք այն համապատասխանում է տեղանքներին խոստացված հասանելիությանը։ Փորձարկեք անցումը նախքան այդ տեղանքներից կախված դառնալը, և յուրաքանչյուր կորցրած սեսիա դիտեք որպես հայտնագործություն, ոչ թե անակնկալ։

Այնտեղ, որտեղ պահանջը իսկապես պարզ է՝ մեկ տեղանք, մեկ նախածանց, առանց համընկնման՝ կառավարվող ծառայությունը սովորաբար հաղթում է գործառնական ծախսով։ Այնտեղ, որտեղ և՛ թարգմանությունը, և՛ դինամիկ երթուղավորումը միասին են՝ սարքի ուղին կարող է լինել միակ հարմարը, և դա պատճառ է ավելի երկար միգրացիա պլանավորելու, ոչ թե չաջակցվող VM-ը պահելու։

Եթե RRAS VM-ն արդեն աշխատում է

Հայտնաբերումը դրա ջնջման պատճառ չէ։ Պլանավորեք փոփոխությունը այն կախվածությունների շուրջ, որոնք այդ VM-ն կուտակել է՝ երթուղիներ, որոնց վրա ապավինում են այլ ենթացանցեր, աղբյուրի հասցեները թաքցնող NAT կանոններ, և այն ամենը, ինչ մոնիտորինգը սովորել է սպասել նրա հասցեից։ Պահպանեք անհրաժեշտ երթուղիները և փորձարկված վերականգնման ուղին, քանի դեռ աջակցվող թիրախը նախագծվում և վավերացվում է կողքին։

Աջակցելիությունը և տեխնիկական ախտորոշումը ողջ ընթացքում պահեք որպես առանձին եզրահանգումներ։ Չաջակցվող դասավորությունը կարող է ունենալ նաև սովորական երթուղավորման սխալ, և այդ սխալի ուղղումը չի փոխում նրա աջակցության կարգավիճակը։ Երկու պնդումներն էլ տեղ ունեն հաշվետվության մեջ, և ոչ մեկը չի չեղարկում մյուսին։

Ավարտեք ուղեցույցը՝ գրանցելով աջակցության մեջբերումը, պահանջների ցանկը, ընտրված փոխարինումը և անցման հերթականությունը։ Այդ չորս կետերն են, որ առաջինը կհարցնի աուդիտորը կամ թիմի նոր անդամը։