Երթևեկության երթուղում երկու մասնաճյուղերի միջև Azure VPN դարպասով
Մեկ Azure VPN դարպասի վրա երկու Site-to-Site կապերը կարող են անցկացնել մասնաճյուղերի երթևեկությունը, բայց միայն այն դեպքում, երբ երկու ծայրերը սովորում են նախածանցը և գոյություն ունի վերադարձի ուղին LAN-ում։
Երկու մասնաճյուղեր կարող են փոխանակել երթևեկություն Azure VPN դարպասով՝ առանց նրանց միջև որևէ ուղղակի թունելի։ Յուրաքանչյուր մասնաճյուղ բացում է Site-to-Site կապ նույն դարպասի հետ, և դարպասը փոխանցում է սովորած նախածանցերը երկու կապերի միջև։ Դա աշխատեցնում է ոչ թե երկրորդ թունելը, այլ երթուղիների փոխանակումը՝ A մասնաճյուղը պետք է սովորի B-ի նախածանցը, իսկ B-ն՝ A-ինը։ Անցեք ստորև ներկայացված ստուգումները հերթականությամբ և կանգ առեք առաջին ձախողվածի վրա, որովհետև յուրաքանչյուր հաջորդ քայլ կախված է դրանից։
Նախապայմաններ, նախքան որևէ բան կարգավորելը
Չորս պայման է որոշում՝ կարո՞ղ է այս նախագիծն ընդհանրապես աշխատել։ Դարպասը պետք է հիմնված լինի երթուղիների վրա և լինի BGP-ն աջակցող SKU-ի վրա, երկու կապերում էլ BGP-ն պետք է միացված լինի, մասնաճյուղերի հասցեային տարածությունները չպետք է համընկնեն, և ոչ մի կողմ չպետք է հենվի NAT-ի վրա՝ իրական նախածանցը թաքցնելու համար։
Պլանավորեք ASN-ները գիտակցաբար։ Azure-ի փաստագրված լռելյայնը 65515-ն է, և յուրաքանչյուր մասնաճյուղի երթուղիչի պետք է իր սեփական մասնավոր ASN-ը, որը չի բախվում դարպասի կամ մյուս մասնաճյուղի հետ։ Լռելյայն արժեքը կրկին օգտագործելը՝ առանց գոյություն ունեցող դարպասի կազմաձևը ստուգելու, այն ուղին է, որով ավելի ուշ AS ուղին մերժվում է։
Նաև հաստատեք, որ չեք ակնկալում VNet peering-ի վարք։ Դարպասը երթուղիներ է փոխանակում ձեր կարգավորած երկու կապերի միջև. այն կամայական peering-ները տրանզիտիվ չի դարձնում։ Եթե երրորդ ցանցը պետք է հասնի երկու մասնաճյուղերին, նրան պետք է սեփական կապ կամ սեփական երթուղի, ոչ թե այն ենթադրությունը, որ դարպասը կբաշխի երթևեկությունը։ Գրեք այդ սահմանը առաջին փոփոխության պատուհանից առաջ, որովհետև դա այն նախագծային որոշումն է, որին մարդիկ վերադառնում են, երբ ավելի ուշ ավելացվում է նոր տեղամաս։
Կարգավորեք այս հերթականությամբ
Յուրաքանչյուր քայլ ունի դիտելի արդյունք, ուստի մի՛ անցեք առաջ, քանի դեռ այն չի հայտնվել։
- Միացրեք BGP-ն վիրտուալ ցանցի դարպասի վրա և նշեք դրա ASN-ը և peer հասցեն։
- Ստեղծեք տեղական ցանցի դարպաս յուրաքանչյուր մասնաճյուղի համար՝ այդ մասնաճյուղի իրական հասցեային տարածությամբ, դրա ASN-ով և BGP peer հասցեով։
- Ստեղծեք յուրաքանչյուր Site-to-Site կապ և միացրեք BGP-ն հենց կապի վրա։
- Կարգավորեք մասնաճյուղի երթուղիչը, որպեսզի peer անի Azure-ի տրամադրած դարպասի հասցեի հետ, ոչ թե ենթադրաբար դարպասի հանրային IKE վերջնակետի հետ։
Չորրորդ քայլն այն տեղն է, որտեղ խրվում են փորձերի մեծ մասը։ Azure-ի հաղորդած BGP peer հասցեն այն է, որը մասնաճյուղի երթուղիչը պետք է օգտագործի որպես հարևան, և դա միշտ չէ այն հասցեն, որ մարդիկ սպասում են թունելի գծապատկերից։
Գովազդեք հենց մասնաճյուղի նախածանցը, օրինակ՝ 10.10.0.0/16 A-ից և 10.20.0.0/16 B-ից։ Չգովազդեք լռելյայն երթուղի կամ լայն ագրեգատ՝ բացակայող կոնկրետ ցանցը ծածկելու համար. բացը հետագայում վերադառնում է որպես լուռ սև խոռոչ։
Ստուգեք երթուղիների փոխանակումը երկու ծայրերում
Կապի կարգավիճակը ստուգում չէ։ IPsec-ը կարող է աշխատել երկու կապերում, մինչ նրանց միջև ոչ մի նախածանց չի անցնում։ Կարդացեք դարպասի BGP peer-ները և դրա սովորած երթուղիները, ապա հաստատեք, որ մյուս մասնաճյուղի ուղղությամբ երթուղին հայտնվում է որպես օգտագործելի ուղի։
| Check | Where | Stop if |
|---|---|---|
| BGP session established | Gateway BGP peers, branch router neighbour state | Session is Idle or Active on either side |
| Prefix learned | Gateway learned routes, branch BGP table | The other branch's prefix is absent |
| Prefix selected | Branch routing table, effective routes on the VNet | Prefix is known but a more specific route wins |
BGP աղյուսակում առկա նախածանցը դեռ կարող է պարտվել փոխանցման որոշումը ստատիկ երթուղու կամ ավելի կոնկրետ նախածանցի։ Ստուգեք ընտրված երթուղին, ոչ միայն ստացվածը։
Հետևեք վերադարձի ուղուն LAN-ի կողմում
Սա այն մասն է, որը Azure-ում ճիշտ է երևում և ձախողվում է տեղում։ A մասնաճյուղի հոսթը իր փաթեթն ուղարկում է A-ի VPN երթուղիչին միայն այն դեպքում, երբ այդ երթուղիչը նրա լռելյայն դարպասն է, կամ երբ հոսթը կամ նրա դարպասը ունի երթուղի B-ի նախածանցի համար։ Նույնը պետք է ճիշտ լինի նաև հակառակ ուղղությամբ։
Եթե առանձին միջուկային կոմուտատորն է LAN-ի լռելյայն դարպասը, ապա նրան պետք է դեպի մյուս մասնաճյուղ երթուղի, որն ուղղված է VPN երթուղիչին։ Առանց դրա հարցումը հասնում է, իսկ պատասխանը դուրս է գալիս ինտերնետի ուղիով, և օգտատերը տեսնում է կապ, որը բացվում է և հետո կախվում։
Սա շտկելու համար մի՛ դիմեք դարպասի ենթացանցի ցանցային անվտանգության խմբին։ Այդ ենթացանցն ունի իր պահանջները, և այնտեղ NSG-ն մասնաճյուղի կողմի քաղաքականության աջակցվող փոխարինող չէ։ Զտումը պետք է լինի մասնաճյուղերի հրահրիչներում և իրենք աշխատանքային ծանրաբեռնվածություններում, որտեղ կանոնները կարող են վերանայել դրանց տերերը։ Այդ կանոնները ենթացանցի NSG տեղափոխելը դրանք թաքցնում է նաև այն թիմից, որը կվրիպազերծի հաջորդ խափանումը։
Թույլատրեք գործողությունը, ապա ապացուցեք այն մերժված փորձարկումով
Սովորած երթուղին թույլտվություն չէ։ Թույլատրեք այն աղբյուրը, նպատակակետը և ծառայությունը, որոնք իսկապես պետք են, մասնաճյուղերի հրահրիչների և վերջնակետի քաղաքականության միջոցով, իսկ մնացածը թողեք արգելված։
Փորձարկեք A մասնաճյուղի սովորական աշխատանքային ծանրաբեռնվածությունից դեպի B մասնաճյուղի իրական ծառայություն, հաստատեք պատասխանը, ապա փորձեք գործողություն, որը պետք է մնա արգելված։ VPN սարքի իսկ ստեղծած երթևեկությունը կարող է օգտագործել այլ աղբյուրի հասցե և շրջանցել LAN երթուղավորման փուլը, ուստի երթուղիչից հաջող ping-ը ապացուցում է ավելի քիչ, քան թվում է։
Ավարտեք՝ գրի առնելով չորս փաստ՝ փոխանակված նախածանցները, օգտագործվող ASN-ները, յուրաքանչյուր կողմի LAN վերադարձի ուղին և ծառայությունը թույլատրող քաղաքականությունը։ Եթե դրանցից մեկը բացակայում է, կարգավորումը աշխատում է մինչև առաջին փոփոխությունը, և հետո ոչ ոք չի կարող բացատրել, թե ինչու։