Сіз порталды ашасыз, Windows Server 2022-ні қосалқы желіге орналастырасыз және Remote Access рөлі ақаусыз орнатылады. Бұл реттілік орнатушының жұмыс істейтінін дәлелдейді, Microsoft-тың бұл конфигурацияны қолдайтынын емес. Azure виртуалды машиналары үшін жарияланған серверлік бағдарламалық қамтамасыз етуді қолдау нұсқаулығы RRAS-ты Azure VM-де қолдауға ие емес Windows Server мүмкіндіктерінің қатарына қосады, және бұл ақаулықтарды жою бөлшегі емес, архитектуралық шешім. Көтерілген туннель орналастыруды қолдау шекарасының ішіне жылжытпайды.

Төмендегі шолу қолдау бетінен басталып, содан кейін талаптар мен ауыстыру нұсқаларына қарай жалғасады.

Зертханадан емес, қолдау бетінен бастаңыз

Бірдеңені өлшемдеу алдында Azure VM қолдау нұсқаулығын оқыңыз. Ол Windows Server-ді бір сараланбаған блок ретінде қарастырудың орнына қолдауға ие өнімдерді, рөлдерді және мүмкіндіктерді ажыратады. Көздеген жұмыс жүктемесі шын мәнінде қай жолға түсетініне назар аударыңыз, өйткені консольде байланысты көрінетін екі құрамдас әртүрлі жолдарда болуы мүмкін.

Бет ашық тұрғанда дәйексөзді жобалау құжатына жазыңыз. Қолдау мәртебесі дереккөзі бар факт, ал оны дәйектеуге қабілетсіз жобалау шолуын демосы бар адам сөзбен жеңеді.

ОЖ қолдауын рөлдер мен мүмкіндіктерді қолдаудан бөліңіз

Сол нұсқаулық Network Policy and Access Services-ті қолдауға ие рөлдердің қатарына қосады, ал RRAS-ты бөлек қолдаусыз деп көрсетеді. Бұл екі жазба әртүрлі нәрселерді сипаттайды, және оларды «қашықтан қатынау қолдауға ие» деп біріктіру жобаның қате оқу негізінде бекітілу жолы. Операциялық жүйенің қолдауға ие болуы өз жолы бар мүмкіндік туралы ештеңе айтпайды.

Шектеу кейде дәйектелгеннен де тар. Ол Azure VM ішінде жұмыс істейтін сол мүмкіндікке қатысты; бұл жеке желі Azure-ға қосыла алмайды дегенді білдірмейді және RRAS барлық жерде қолдаусыз деп те айтпайды. Пакеттерді дұрыс жіберетін ескі зертхана пакеттер туралы дәлел, қолдау мәлімдемесі туралы емес.

Жобаның қалған бөлігінде осы екі сұрақты бөлек ұстаңыз: ол жұмыс істей ме және ол қолдауға ие ме. Әрқайсысы үшін әртүрлі жауаптар және кейде әртүрлі жауаптылар қажет болады.

Жобалау шын мәнінде не істеуі керектігін жазыңыз

Ауыстырғышты таңдамас бұрын сайттар тізімін өнімді өлшеуге болатын талаптарға айналдырыңыз:

  • Филиал құрылғылары әлдеқашан сөйлейтін туннель протоколдары және қандай да бір сайтқа динамикалық маршруттау қажет пе.
  • Қашықтағы префикстер, маршруттау емес, аударма қажет ететін кез келген қабаттасатын мекенжай кеңістігін қоса.
  • Azure-бен маршрут алмасу және маршруттау кестесінің әр жазбасының иесі кім.
  • Ең қарқынды сағатқа төтеп беруі тиіс өткізу қабілеті мен қосылымдар саны.
  • Сайт иелері келіскен ақаулық ауысу мінез-құлқы, тек сіз сала алатын нұсқа емес.

NAT — назардан тыс қалатын, содан кейін бүкіл жобалауды шешетін тармақ. IPsec орната алатын құрылғы ауыстырып отырған RRAS орналастыруынан өзгеше мекенжайларды аударуы мүмкін, және бұл филиалдың қандай мекенжайларды дереккөз ретінде көретінін және журналдарыңыздың нені жазатынын өзгертеді.

Тізімді желі иелеріне апарыңыз және кез келген өнім талқылауының алдында растаңыз. Анық емес талаптар әрбір жеткізуші салыстыруын талғам дауына айналдырады.

Ауыстырғыштарды осы талаптарға қарсы бағалаңыз

Azure-дың басқарылатын қосылым қызметтері мен жеткізушілер қолдайтын желілік виртуалды құрылғылардың екеуін де бір тізімге қарсы бағалау керек. IPsec-ті аяқтай алады деп, олардың кез келгенін RRAS VM-нің тікелей баламасы деп есептемеңіз: NAT моделі мен маршруттардың меншігі және жоғары қолжетімділік жобалауы қолданыстағы сайттардың қалай қосылатынын және олардың жауаптары қайда қайтатынын анықтайды. Әр үміткерді қағазда тізімге қарсы бағалап, қай талаптарды орындамайтынын жазыңыз, өйткені дәл сол жазба таңдауды кейін тексеруге болатын етеді.

Екі құрылғы VM-нің алдындағы жүктеме теңгерушісі өздігінен жоғары қолжетімділік емес. Ол фронтенд береді, синхрондалған туннель күйін емес, ал әрбір сеансты тастайтын ауысу — біреу әдейі қабылдауы тиіс жобалау шешімі. Құрылғы жеткізушісінен қолдауға ие HA үлгісі қандай және ол сайттарға уәде етілген қолжетімділікке сәйкес пе, сұраңыз. Сол сайттар оған тәуелді болмас бұрын ауысуды тексеріңіз және әрбір жоғалған сеансты тосынсый емес, табылған мәселе ретінде қарастырыңыз.

Талап шын мәнінде қарапайым болғанда — бір сайт, бір префикс, қабаттасу жоқ — басқарылатын қызмет әдетте операциялық шығында жеңеді. Аударма мен динамикалық маршруттау екеуі де ойында болғанда, құрылғы жолы жалғыз қолайлы болуы мүмкін, және бұл қолдаусыз VM-ді ұстаудың орнына ұзағырақ көшіруді жоспарлауға себеп.

Егер RRAS VM әлдеқашан жұмыс істеп тұрса

Анықтау оны жоюға себеп емес. Өзгерісті сол VM жинақтаған тәуелділіктердің айналасында жоспарлаңыз: басқа қосалқы желілер сүйенетін маршруттар, дереккөз мекенжайларын жасыратын NAT ережелері және мониторинг оның мекенжайынан күтуді үйренгеннің бәрі. Қолдауға ие мақсат қатар жобаланып, тексеріле тұрғанда қажетті маршруттар мен сыналған қалпына келтіру жолын сақтаңыз.

Қолдауға қабілеттілік пен техникалық диагностиканы бүкіл уақыт бойы бөлек тұжырымдар ретінде ұстаңыз. Қолдаусыз орналасуда қарапайым маршруттау қатесі де болуы мүмкін, және бұл қатені түзету оның қолдау мәртебесін өзгертпейді. Екі тұжырым да есепке тиесілі, және ешқайсысы екіншісін жоймайды.

Шолуды қолдау дәйексөзін, талаптар тізімін, таңдалған ауыстырғышты және көшу ретін жазып аяқтаңыз. Аудитор немесе жаңа топ мүшесі бірінші кезекте осы төрт элементті сұрайды.

Қатысты мақалалар