Ինչու է Azure VPN նախածանցի ավելացումը կտրում կապը
Հեռավոր նախածանցը գտնվում է տեղական ցանցի դարպասում, ոչ VNet-ում: Այն փոխելը հեռացնում է կապը. դարպասը մնում է անձեռնմխելի:
Սխալ Azure օբյեկտին ավելացված նախածանցը ստեղծում է կապ, որը հայտնում է Connected և ոչինչ չի փոխանցում, և սա այս կույտի ամենաթանկ սխալի տեսակն է: Ներգրավված են երեք ռեսուրս, և դրանցից միայն մեկն է տիրապետում հեռավոր հասցեային տարածությանը՝ վիրտուալ ցանցի դարպասը, հեռավոր կողմը նկարագրող տեղական ցանցի դարպասը և դրանք միացնող կապը: Նախածանցը պատկանում է տեղական ցանցի դարպասին, կապը պետք է վերակառուցվի, որպեսզի փոփոխությունն ուժի մեջ մտնի, իսկ դարպասն ինքը սովորաբար մնում է անձեռնմխելի: Հերթականությունը ենթակա չէ բանակցության, և պորտալը ցույց է տալիս դրա միայն մի մասը:
Երեք օբյեկտ, որոնցից մեկը պահում է նախածանցը
Վիրտուալ ցանցի հասցեային տարածությունը պատասխանում է մեկ այլ հարցի՝ ինչ է ապրում Azure-ի ներսում: Այնտեղ հեռավոր նախածանց ավելացնելը երթևեկությունը այնտեղ չի ուղղում, այն միայն ընդլայնում է այն տարածությունը, որը հարթակը կարծում է, թե իրենն է, ինչը կարող է բախվել իրական հեռավոր միջակայքի հետ: Տեղական ցանցի դարպասը այն օբյեկտն է, որը պահում է հեռավոր նախածանցները, և կապը հղում է երկու դարպասներին գումարած նախապես համօգտագործված բանալին:
Կա նաև երրորդ վերապահում, որը պետք է հիշել: GatewaySubnet հյուրընկալում է կառավարվող դարպասի օրինակները, պետք է կրի հենց այդ անունը, և ոչ Basic SKU-ների համար ակնկալվում է, որ այն կլինի առնվազն /27:
Ուրիշ ոչինչ չի պատկանում այդ ենթացանցին, և նախածանցի փոփոխությունը պատճառ չունի դրան դիպչելու: Տեղական ցանցի դարպասում բացակայող նախածանցը հասանելի չէ, ինչ էլ ասի կապի կարգավիճակը, որովհետև դարպասը թունելը բանակցելիս առաջարկում է միայն այն նախածանցները, որոնց մասին իրեն տեղեկացրել են: Դրա համար ախտանիշը ասիմետրիկ է՝ թունելը վերևում է, անվտանգության ասոցիացիան կարգին է, և մեկ ենթացանց երբեք չի հայտնվում երթևեկության ընտրիչներում: Եթե մեկ հեռավոր միջակայք բացակայում է, մինչ հարևանները աշխատում են, դադարեցրեք թունելին նայելը և կարդացեք տեղական ցանցի դարպասը:
Ինչու է հեռացվում հենց կապը
Կապի օբյեկտը ամրագրում է բանակցված կոնֆիգուրացիան իր ողջ կյանքի ընթացքում: Դրա համար փաստաթղթավորված ընթացակարգը սկզբում հեռացնում է կապը, թարմացնում տեղական ցանցի դարպասը, ապա վերստեղծում կապը նույն համօգտագործված բանալիով: Դարպասի օրինակները չեն վերակառուցվում միայն նախածանցի փոփոխության համար, ինչը ընդհատումը սահմանափակում է կապի քանդմամբ՝ դարպասի վերատեղակայման փոխարեն:
Այդ ջնջումը հենց ընդհատումն է, ուստի վերաբերվեք դրան որպես սկիզբ և ակնկալվող ավարտ ունեցող պլանավորված փոփոխության, ոչ թե արագ խմբագրման: PowerShell-ում հաջորդականությունը կարճ է: Remove-AzVirtualNetworkGatewayConnection -Name Conn1 -ResourceGroupName RG1 -Force, ապա Set-AzLocalNetworkGateway նոր -AddressPrefix զանգվածով, ապա New-AzVirtualNetworkGatewayConnection նույն -SharedKey և նույն դարպասներով: Բանալու վերօգտագործումը կարևոր է, որովհետև հեռավոր կողմը չի վերակազմաորվում, և նոր բանալին նշանակում է համակարգում նրա հետ, ով տիրապետում է հեռավոր սարքին: Եթե այդ սարքը կառավարում է մեկ այլ թիմ, նրանց հետ պայմանավորվեք ժամանակահատվածի շուրջ նախքան ինչ-որ բան հեռացնելը:
Երբ պետք է վերակառուցվի ինքը դարպասը
Այս խնդրի շուրջ պտտվող երկրորդ պատասխանն ասում է, որ դարպասը պետք է վերստեղծվի, իսկ բանալին՝ նորից փոխանակվի: Դա ճիշտ է գործողությունների մեկ այլ հավաքածուի համար՝ դարպասի տեսակի կամ SKU-ի փոփոխում, point-to-site-ի և site-to-site-ի միջև անցում, կամ այնպիսի դարպասի վերանորոգում, որի սեփական կոնֆիգուրացիան սխալ է: Այդ փոփոխություններն իսկապես փոխում են դարպասի ռեսուրսը, ուստի վերակառուցումն իսկապես անհրաժեշտ է:
Point-to-site-ի համար ստեղծված դարպասին չի կարելի պարզապես site-to-site կապ տալ: Point-to-site կոնֆիգուրացիան պետք է հեռացվի, և դարպասը՝ վերստեղծվի, ինչը նաև տալիս է նոր համօգտագործված բանալի և նոր հաճախորդային փաթեթ:
Point-to-site փաթեթն արժանի է առանձին նշումի, որովհետև այն ժամկետանց է դառնում: Պորտալը ստեղծում է կարճ կյանք ունեցող ֆայլ, ուստի գործնական մոտեցումն այն է՝ ներբեռնել այն մեկ անգամ և տարածել հաճախորդի վկայագրի հետ միասին՝ օգտատերերին պորտալի հղում ուղարկելու փոխարեն, որը մեռած կլինի, երբ նրանք սեղմեն: Նախածանցի հարցին այս ամենից ոչինչ չի վերաբերում: Երկու ընթացակարգերն առանձին պահելը ողջ կարգապահությունն է՝ նախածանցները կապի մակարդակի փոփոխություն են, իսկ դարպասի հատկությունները՝ դարպասի մակարդակի փոփոխություն:
Կարդացեք վիճակը, ոչ թե պորտալի կրծքանշանը
Կարդացեք վիճակը ռեսուրսից, ոչ թե պորտալի կրծքանշանից: Get-AzVirtualNetworkGatewayConnection -Name Conn1 -ResourceGroupName RG1 վերադարձնում է ConnectionStatus մուտքային և ելքային բայթերի հաշվիչների հետ միասին, և հենց հաշվիչներն են տարբերում միացված, բայց ոչինչ չտեղափոխող թունելը նրանից, որը երբեք չի հաստատվել:
Այն հաշվիչները, որոնք փոխանցման կեսին դադարում են աճել, մատնանշում են ուղին, ոչ թե նույնականացումը. Իսկ հաշվիչները, որոնք ընդհանրապես չեն շարժվում, մատնանշում են նախածանցների հավաքածուն կամ համօգտագործված բանալին:
Ժամաչափերը բացատրում են անջատումների մի դաս, որոնք սխալմամբ վերագրվում են VPN-ին: Azure-ի բեռնվածքի հավասարակշռիչը փակում է պարապ հոսքերը իր կարգավորված ժամկետից հետո՝ լռելյայն չորս րոպե, երբ գրվել են այս նշումները, և կարգավորելի է դեպի վեր, ուստի keepalive-ով չապահովված VM-ի վրա OpenVPN սերվերը կարող է ընկնել ամեն մի քանի րոպեն մեկ, մինչ մնացած ամեն ինչ առողջ է թվում: Դարպասը, որը հարթակը ցիկլորեն վերագործարկում է, նույնպես կարող է ընդհատել VNet կապը Web App-ի հետ, և այդ ձախողումը հարթակի կողմում է, ոչ թե հաճախորդի կոնֆիգուրացիայում: Նշանն այն է՝ անջատումը հետևում է ֆիքսված ինտերվալի, թե ձեր արած փոփոխությանը:
Պահեք երեք օբյեկտները և դրանց արժեքները մեկ գրառման մեջ՝ վիրտուալ ցանցի հասցեային տարածությունը, տեղական ցանցի դարպասի նախածանցների ցանկը և կապի համօգտագործված բանալու հղումը: site-to-site PowerShell հոդվածը փաստաթղթավորում է տեղական ցանցի դարպասի հրամանները և այն հերթականությունը, որին դրանք պատկանում են: Նախածանցի փոփոխությունը հիշողության հետ համեմատելն այն է, թե ինչպես աշխատող թունելը երկու անգամ վերակառուցվում է:
Այնուհետև ստուգեք այն հերթականությամբ, որով փոխել եք՝ տեղական ցանցի դարպասը ցույց է տալիս նոր նախածանցների ցանկը, կապը կրկին Connected է, և հաշվիչները շարժվում են, երբ երթևեկություն եք ուղարկում նոր միջակայքի հոսթին: Եթե երրորդ քայլը ձախողվի, մինչ առաջին երկուսը անցնում են, հեռավոր կողմը չի ընդունել նոր երթևեկության ընտրիչը, և հեռավոր սարքին անհրաժեշտ է համապատասխան 2-րդ փուլի գրառումը: Սա զրույց է թունելի մյուս ծայրի հետ, ոչ թե ևս մեկ փոփոխություն Azure-ում: