Ինչու է կետից կայք միացմանը անհրաժեշտ երթուղային Azure VPN դարպաս
Քաղաքականության վրա հիմնված դարպասը թունելի միջերես չունի հաճախորդների երթուղիների համար։ Ինչ պետք է վերակառուցել, ինչ հերթականությամբ, և որ սահմանափակումներն են մնում փոխարինումից հետո։
Քաղաքականության վրա հիմնված դարպասը կառուցում է IPsec թունել, որը ընտրվում է երթևեկության ընտրիչներով, և չունի միջերես՝ հաճախորդների երթուղիները հանձնելու համար։ Կետից կայք միացումը երթուղավորման հատկություն է՝ դարպասը տիրապետում է հաճախորդների հասցեների լողավազանի և տեղադրում է երթուղիներ այդ հաճախորդներին վիրտուալ ցանցում։ Այդ անհամապատասխանությունն է պատճառը, որ պորտալը դրա ավելացման ոչ մի տարբերակ չի ցուցադրում։ Գոյություն ունեցող դարպասի վրա ոչինչ հնարավոր չէ միացնել՝ միջերեսը ստեղծելու համար, ուստի փոփոխությունը փոխարինում է, այլ ոչ թե կազմաձևի խմբագրում։
Հերթականությունն ավելի կարևոր է, քան առանձին քայլերը։ Եթե հաջորդականությունը սխալ լինի, կայք-կայք ընդմիջումը կանցնի սպասարկման պատուհանից այն կողմ։
Ինչ է իրականում անում քաղաքականության վրա հիմնված դարպասը
Քաղաքականության վրա հիմնված դարպասը փաթեթները համեմատում է միացման վրա կարգավորված երթևեկության ընտրիչների հետ և համընկնումները ուղարկում մեկ թունել։ Չկա հասցեով թունելի միջերես, և վիրտուալ ցանցում ոչ մի տեղ չի հայտնվում մեկ հաճախորդի երթուղի։ Երթուղիների աղյուսակը պարզապես ստանում է դարպասին ուղղված տեղական նախածանցերը։ Այդ մոդելը բավարար է երկու հաստատուն հասցեային տարածությունների միջև կայք-կայք միացման համար։
Երթուղային դարպասը աշխատում է հակառակը՝ այն ներկայացնում է թունելի միջերես, և երթուղիներն են որոշում, թե ինչ է մտնում դրա մեջ։ Կետից կայք միացումը և ցանկացած ձևավորում, որի գործընկերների հավաքածուն փոխվում է, կախված են այդ միջերեսի գոյությունից։
Ինչու է հաճախորդների լողավազանին պետք այդ միջերեսը
Երբ նոութբուքը միանում է, դարպասը նրան հասցե է հատկացնում կետից կայք լողավազանից։ Այնուհետև վիրտուալ ցանցին պետք է երթուղի, որն ասում է, որ այդ հասցեն հասանելի է դարպասի միջոցով։ Առանց թունելի միջերեսի չկա մի բան, որին կցել այդ երթուղին։
Լողավազանը գալիս է ձեր նշած միջակայքից, և դարպասը բաշխում է դրանից։ Եթե այդ միջակայքը համընկնում է տեղական ցանցի կամ զուգակցված վիրտուալ ցանցի հետ, հակամարտությունը երևում է միայն հաճախորդի միանալուց հետո, ինչը վատ պահ է այն հայտնաբերելու համար։ Վերապահեք լողավազանը մինչև միգրացիայի մեկնարկը։
Տեսակը նույնպես միացման համար առանձին կարգավորում չէ։ Մեկ դարպասն ունի մեկ տեսակ, և դրա պահած յուրաքանչյուր միացում վարվում է համապատասխանաբար, ուստի խառը ձևավորմանը պետք է երկրորդ դարպաս, այլ ոչ թե երկրորդ միացում։
Տեսակը ֆիքսվում է ստեղծման պահին
Microsoft-ը նշում է, որ վիրտուալ ցանցի դարպասը տեղակայումից հետո հնարավոր չէ փոխել քաղաքականության վրա հիմնվածի և երթուղայինի միջև։ Չկա փոխարկման հրաման և պորտալում՝ անջատիչ։ Երկրորդ դարպաս ստեղծելը նույն ենթացանցում նույնպես լուծում չէ, քանի որ Azure-ը թույլատրում է մեկ դարպաս յուրաքանչյուր վիրտուալ ցանցի համար։ Հետևաբար միգրացիան հեռացնելն է, վերակառուցելը և նորից միանալը։
Դա նաև SKU-ի որոշումը ներառում է նույն կառուցման մեջ։ Ավելի ուշ ավելի մեծ SKU-ի անցնելը ևս մեկ դարպասի փոխարինում է ևս մեկ ընդմիջումով։
Մեկ դարպաս, մեկ GatewaySubnet
Դարպասը ապրում է GatewaySubnet անունով ենթացանցում, և այն զբաղեցնում է միայն մեկ դարպաս։ Այդ ենթացանցի չափորոշումը ներառված է նախապատրաստման մեջ, քանի որ ավելի մեծ SKU-ին ավելի շատ հասցեներ են պետք, և ենթացանցը հետագայում հնարավոր չէ փոքրացնել։ Գրանցեք ընթացիկ կայք-կայք կարգավորումները, ընդհանուր բանալին, տեղական ցանցի դարպասը և արդյունավետ երթուղիները, նախքան որևէ բանի դիպչելը։ Այնուհետև վերաբերվեք պատուհանին որպես ընդմիջման, քանի որ կայք-կայք թունելը մնում է անջատված, մինչև նոր միացումը կարգավորվի։
Վերակառուցման հերթականություն, որը սահմանափակում է ընդմիջումը՝ ստեղծեք երթուղային դարպասը, նորից ստեղծեք կայք-կայք միացումը նույն տեղական ցանցի դարպասին, հաստատեք թունելը և մեկ հոսթ-հոսթ հարցում, և միայն դրանից հետո ավելացրեք կետից կայք միացումը և ստեղծեք նոր հաճախորդի փաթեթ։
Ինչ չի շտկում փոխարինումը
Երկրորդ սահմանափակումը պատկանում է գործընկերոջը, ոչ թե Azure-ին։ Քաղաքականության վրա հիմնված տեղական սարքը կարող է հասնել միայն այն վիրտուալ ցանցին, որին միանում է, և չի կարող անցնել այլ տեղական ցանցեր կամ այլ վիրտուալ ցանցեր նույն դարպասով։ Azure-ի կողմի փոխարինումը չի փոխում այն, ինչ գործընկերը կարող է ընտրել։
Եթե պահանջը իսկապես կայքերի միջև տարանցում է, պատասխանը երթուղային գործընկեր սարքն է կամ տոպոլոգիա, որտեղ յուրաքանչյուր նպատակ ավարտվում է առանձին։ Որոշեք դա նախքան ամսաթիվ խոստանալը, քանի որ միայն դարպասի փոխարինումը դա չի ապահովի։
Գործողությունների և ստուգումների հերթականությունը
Ստուգեք յուրաքանչյուր հնարավորություն առանձին։ Սկզբում կայք-կայք թունելի կարգավիճակը և մեկ հոսթ-հոսթ հարցում, ապա կետից կայք միացում և մեկ մասնավոր ռեսուրս, ապա ցանկացած տարանցման ուղի, որը պնդում է ձևավորումը։ Կանաչ դարպասի կարգավիճակը ապացուցում է միայն, որ անվտանգության ասոցիացիան բարձրացել է, և ոչ ավելին։ Պահեք ստուգումները այդ հերթականությամբ, որպեսզի ձախողումը մատնանշի այն փուլը, որը ներմուծել է այն։
Ցանկացած տոպոլոգիայի փոփոխությունից հետո նորից ստեղծեք հաճախորդի փաթեթները և լողավազանը հեռու պահեք բոլոր տեղական և զուգակցված միջակայքերից։ Սահմանափակումները և SKU-ի տարբերությունները հավաքված են Azure VPN Gateway-ի կարգավորումների տեղեկագրում։