Արդյո՞ք զուգակցված Azure VNet-ին պետք է իր սեփական VPN դարպասը
Զուգակցված VNet-ը կարող է օգտագործել hub-ի VPN դարպասը աջակցվող SKU-ով և մեկ կարգավորումով peering-ի յուրաքանչյուր ուղղությամբ։ Ստուգեք արդյունավետ երթուղիները, ոչ թե peering-ի կարգավիճակը։
Հայտնվում է նոր spoke VNet, hub-ն արդեն ունի աշխատող site-to-site դարպաս, և ակնհայտ հարցն այն է՝ պե՞տք է վճարել երկրորդ դարպասի համար։ Սովորաբար ոչ՝ դարպասի տրանզիտը թույլ է տալիս spoke-ին օգտագործել hub-ի դարպասը peering-ի միջոցով։ Երեք պայման է որոշում՝ կաշխատի՞ դա, և դրանցից ոչ մեկը չի երևում peering-ի կարգավիճակի նշանից։ Peering-ի կապակցվածությունը և ուրիշի դարպասն օգտագործելու թույլտվությունը առանձին կարգավորումներ են, ուստի երկու VM, որոնք արդեն կարող են ping անել միմյանց, ոչինչ չեն ապացուցում VPN ուղու մասին։
Առաջին պայմանը՝ դարպասը և spoke-ում դրա բացակայությունը
Azure-ը դարպասի տրանզիտն աջակցում է Basic-ից բացի այլ VPN Gateway SKU-ների համար, և այն կարող են կրել ինչպես տարածաշրջանային, այնպես էլ գլոբալ peering-ը։ Spoke-ը սպառում է դարպաս, որը չի պատկանում իրեն, ուստի չի կարող ունենալ սեփականը՝ եթե spoke-ում արդեն կա դարպաս, կամ հեռավոր դարպասի տարբերակն արդեն ընտրված է, ցանկալի տրանզիտի կարգավորումը կլինի անհասանելի կամ անարդյունավետ։ Ստուգեք դա նախքան որևէ բան վրիպազերծելը, որովհետև անջատված նշատուփը ախտանիշն է, ոչ թե խափանումը։ Նախ կարդացեք SKU-ն և գոյություն ունեցող դարպասը, ապա նայեք peering-ի կարգավորումներին։
Չջնջեք գոյություն ունեցող spoke-ի դարպասը, որպեսզի տարբերակը հայտնվի, մինչև չիմանաք, թե ինչն է դրանից կախված։ Միգրացիայի հերթականությունն ավելի կարևոր է, քան նշատուփը։
Երկրորդ պայմանը՝ մեկ կարգավորում peering-ի յուրաքանչյուր ուղղությամբ
Peering-ը երկու օբյեկտ է՝ մեկը յուրաքանչյուր VNet-ում, և տրանզիտի կարգավորումները գտնվում են այդ զույգի տարբեր կողմերում։ Hub-ի peering-ը դեպի spoke պետք է թույլ տա hub-ի դարպասին սպասարկել spoke-ին, spoke-ի peering-ը դեպի hub պետք է ընդունի hub-ի դարպասը։ Microsoft-ի դարպասի տրանզիտի ուղեցույցը դրանք անվանում է ըստ ուղղության, և դա դրանք ճիշտ պահելու միակ միջոցն է՝
| Peering direction | What to enable |
|---|---|
| Hub → spoke | Allow gateway transit on the hub's peering |
| Spoke → hub | Use remote gateways on the spoke's peering |
remote պիտակով կառավարման տարրը փոխում է իմաստը՝ կախված նրանից, թե որ VNet-ի peering-ն եք խմբագրում, ուստի կարդացեք ուղղությունը, ոչ թե բառը։ Սահմանեք երկու կողմերը, պահեք և հաստատեք, որ peering-ը երկու տեղերում էլ միացված է հաղորդում։
Երրորդ պայմանը՝ հասցեային տարածքը և թույլտվությունների սահմանները
Տրանզիտը չի կարող ստիպել, որ նույն նպատակակետային նախածանցը նշանակի երկու ցանց, ուստի hub-ի, spoke-ի և տեղական ցանցի միջակայքերը պետք է չհատվեն, նախքան սրանից որևէ բան կաշխատի։ VNet-երը կարող են լինել նաև տարբեր բաժանորդագրություններում կամ տարբեր վարձակալներում՝ դա արգելք չէ, բայց յուրաքանչյուր peering ստեղծող կամ թարմացնող ինքնությունը պետք է ունենա անհրաժեշտ թույլտվությունները այդ ցանցում։ Բաժանորդագրությունների միջև փոփոխությունները հաճախ ձախողվում են թույլտվությունների պատճառով, և սխալը հեշտ է սխալ կարդալ որպես տոպոլոգիայի խնդիր։
Փոփոխությունից առաջ գրեք միջակայքերը և սեփականատերերին։ Երկուսից որևէ մեկի գուշակումը ստեղծում է peering, որը միանում է և ոչինչ չի երթուղավորում։
Ստուգեք արդյունավետ երթուղիներով, ոչ թե peering-ի կարգավիճակով
Նայեք spoke-ի աշխատանքային բեռի ցանցային ինտերֆեյսի արդյունավետ երթուղիներին և գտեք տեղական ցանցի իրական նախածանցը։ Ստուգեք ենթացանցի երթուղիների աղյուսակը և արդյոք դարպասի երթուղիների տարածումը անջատված է, քանի որ օգտատիրոջ կողմից սահմանված երթուղին կամ ստուգման սարքը կարող է վերազանցել այն ուղին, որը ենթադրում են peering-ի դրոշակները։ Ապա հաստատեք մյուս ուղղությունը՝ տեղական ցանցը պետք է իմանա, թե ինչպես հասնել spoke-ի նախածանցին site-to-site կապի միջոցով՝ թե՛ սովորած հայտարարություններով, թե՛ հստակ երթուղով և հաճախորդի սարքում համապատասխան պաշտպանված ցանցի գրառմամբ։ Եթե նախածանցը բացակայում է կողմերից որևէ մեկում, peering-ի դրոշակները չեն, որ պետք է փոխել։
Փորձեք մեկ ծառայություն spoke-ի աշխատանքային բեռից և հետևեք պատասխանին։ VPN դարպասից կամ hub-ի VM-ից փորձարկումը կիրառում է այլ աղբյուրի նախածանց և այլ ուղի։
Եթե տոպոլոգիան սպասարկում է նաև point-to-site հաճախորդներին, առանձին ստուգեք նրանց տեղադրված երթուղիները։ Windows հաճախորդի փաթեթները կարող են վերագեներացման կարիք ունենալ տոպոլոգիայի փոփոխությունից հետո, և սա հաճախորդի երթուղավորման խնդիր է, ոչ թե ապացույց, որ դարպասի համօգտագործումը ձախողվել է։
Ինչ չի տալիս դարպասի համօգտագործումը
Դարպասի տրանզիտը երթուղավորման հարմարավետություն է, ոչ թե լիազորում։ Ցանցային անվտանգության խմբերը, տեղական զտիչները և ծառայության մակարդակի կանոնները դեռ որոշում են, թե ինչին կարող է հասնել spoke-ի աշխատանքային բեռը, ուստի միացրեք կոնկրետ աղբյուրից նպատակակետ ծառայությունը՝ փոխարենը ենթադրելու, որ ընդհանուր թունելը թույլատրում է ամեն ինչ իր հետևում։
Peering-ը նույնպես անցողիկ չէ այնպես, ինչպես մարդիկ հույս ունեն։ Եվս մեկ spoke կամ մասնավոր վերջնակետ ավելացնելը բերում է իր երթուղավորման և մուտքի պահանջները, որոնք գոյություն ունեցող տրանզիտի կարգավորումը չի ծածկում։