Երկու տեղական VPN հասցեներ՝ Azure-ի երկու զուգընկեր, ոչ թե մեկը
Երկրորդ տեղական VPN հասցեն ևս մեկ զուգընկեր է, ոչ թե երկրորդ դաշտի արժեք։ Մեկ տեղական ցանցի դարպաս և մեկ կապ յուրաքանչյուր սարքի համար, ապա հաշվեք թունելները։
Դիագրամում ճյուղում կա ինտերնետի երկու կապ և Azure-ում մեկ VPN դարպաս, ուստի տեղական ցանցի դարպասը ստանում է երկու հանրային հասցեները։ Այն կոկիկ է թվում և չի աշխատում այնպես, ինչպես ենթադրում է դիագրամը։ Յուրաքանչյուր տեղական VPN սարք առանձին զուգընկերային հարաբերություն է, և Microsoft-ի բազմասարքային ձևավորումը յուրաքանչյուրին տալիս է իր տեղական ցանցի դարպասի ռեսուրսը և իր կապը։ Երկրորդ հասցե ավելացնելը մեկ ռեսուրսին չի ստեղծում երկրորդ զուգընկեր։ Այն ստեղծում է ռեսուրս, որը պատշաճ կերպով չի նկարագրում սարքերից ոչ մեկը։
Առասպելը՝ մեկ դարպաս, երկու հասցե
Տեղական ցանցի դարպասը հեռավոր զուգընկերի նկարագրությունն է՝ մեկ հանրային վերջնակետ և դրա հետևում գտնվող մասնավոր նախածանցները։ Չկա աջակցվող եղանակ այդ ռեսուրսին «այս երկու սարքերից որևէ մեկը» իմաստը տալու համար։
Նույն շփոթությունը կա նաև հակառակ ուղղությամբ, որտեղ Azure-ի երկու հանրային IP-ները կարդացվում են որպես երկու Azure դարպասների գոյության ապացույց։
Հաշվեք օբյեկտները, ապա՝ թունելները
Վերցրեք երկու ինքնուրույն կառավարվող տեղական սարքեր, յուրաքանչյուրն իր հանրային հասցեով և նույն մասնավոր ցանցերի հասանելիությամբ, գումարած մեկ երթուղային Azure դարպաս ակտիվ-ակտիվ ռեժիմում։ Azure դարպասն ունի երկու ակտիվ օրինակ՝ առանձին հանրային IP-ներով։ Յուրաքանչյուր տեղական սարք միանում է երկու օրինակներին։ Սա ամբողջական ցանցն է, և օբյեկտների քանակը բխում է դրանից, ոչ թե դիագրամից։
Թվաբանությունը բավական կարճ է նախագծային փաստաթղթում տեղադրելու համար՝
2 on-premises VPN devices
2 local network gateway resources
2 connection resources
4 IPsec tunnels in the complete 2 x 2 mesh
Մեկ կապի ռեսուրսը կարող է կրել մեկից ավելի հիմքային թունել, ուստի չորս թունել չի նշանակում չորս վիրտուալ ցանցի դարպաս։ Azure-ի երկու հանրային IP-ները նույնպես նույն օբյեկտները չեն, ինչ հեռավոր վայրը նկարագրող երկու տեղական ցանցի դարպասները։
Ինչ է ավելացնում ակտիվ-ակտիվը Azure-ի կողմում
Ակտիվ-ակտիվը Azure դարպասը մեկ ակտիվ օրինակից դարձնում է երկու՝ յուրաքանչյուրն իր հանրային IP-ով, և հենց դա է ամբողջական ցանցը հնարավոր դարձնում։ Այն չի կրկնապատկում մեկ հոսքի թողունակությունը։ Այն նաև չի վերացնում տեղական կողմի՝ հավասար արժեքով բազմուղի աջակցելու անհրաժեշտությունը, եթե երկու սարքերն էլ միաժամանակ փոխանցեն։ Նախքան որևէ բան տրամադրելը հաստատեք դարպասի ռեժիմը, SKU-ն և հեռավոր սարքի հնարավորությունները։
Պասիվ սպասման դարպասը լիովին վավեր ձևավորում է. այն պարզապես տալիս է թունելների այլ քանակ։
BGP-ն երկու ուղիներն էլ դարձնում է օգտագործելի
Բազմասարքային ձևավորման համար երկու տեղական սարքերն էլ աշխատեցնում են BGP։ Տվեք յուրաքանչյուրին եզակի BGP զուգընկերի հասցե և հայտարարեք նույն նախատեսված մասնավոր նախածանցները համապատասխան ուղիներով։ Մասնավոր նախածանցները նույնականացնում են պաշտպանված ցանցերը, իսկ հանրային հասցեները՝ որտեղ են ավարտվում գաղտնագրված կրիչային կապերը։ Երկուսը շփոթելը տալիս է ձևավորում, որտեղ բոլոր թունելները բարձրացված են, իսկ երթուղիները՝ սխալ։
Պլանավորեք վերադարձի երթուղավորումը և ցանկացած վիճակային ստուգում, որը պետք է դիմանա երկու ուղիներից որևէ մեկին։ Ամեն վերջնակետում առողջ IKE սեսիան չի ապացուցում, որ աշխատանքային ծանրաբեռնվածությունը կարող է օգտագործել յուրաքանչյուր հայտարարված երթուղի։
Հոսքային ընտրությունը թողունակության միավորում չէ
Azure-ն յուրաքանչյուր հոսքի համար ուղի է ընտրում հոսքի հասցեների և պորտերի վրա հեշի միջոցով։ Կայուն վիճակում տվյալ TCP կամ UDP հոսքի փաթեթները սովորաբար անցնում են նույն թունելով, և տեղական կողմը կարող է այլ թունել ընտրել վերադարձի ուղղության համար։ Այսպիսով՝ երկու սարք և չորս թունել բարելավում են հասանելիությունը, ոչ թե մեկ փոխանցման արագությունը։ Երբ մատակարարի սլայդը խոստանում է միավորում, այն նկարագրում է այլ գործառույթ կամ թյուրիմացություն։
Փորձարկեք զուգահեռ հոսքերով, եթե ուզում եք տեսնել ուղիների տարածումը, և մեկ հոսքով, եթե ուզում եք տեսնել սահմանը։
Ինչ ավելորդություն եք իրականում հեռացրել
Մեկ սարքի վրա երկու WAN հասցե բարելավում է մուտքի կապի ընտրանքները՝ միաժամանակ կիսելով այդ սարքի սնուցումը, ծրագրաշարը և խափանման վիճակը։ Դրանք նույնը չեն, ինչ երկու սարք, և Azure-ի կողմի ոչ մի կարգավորում դա չի փոխում։ Հետևեք մատակարարի աջակցվող երկակի WAN կամ կլաստերային ձևավորմանը՝ հասցեների քանակից ավելորդություն եզրակացնելու փոխարեն։ Ապա փորձարկեք. հերթով հեռացրեք մեկ ուղի և հաստատեք մնացած երթուղիները և իրական հավելվածի փոխանակումը երկու ուղղություններով։
Սպասեք հայտնաբերման և կոնվերգենցիայի ուշացումներ, և սպասեք, որ որոշ գործող սեսիաներ կավարտվեն։