Ինչու VPN-ի վրայով BGP-ն չի կառավարում ձեր ստորին շերտի ուղին
VPN-ի վրայով BGP-ն փոխանակում է հասանելիություն և կիրառում է երթուղու քաղաքականություն, բայց ստորին շերտը դեռ ընտրում է արտաքին ուղին։ Ինչ է իրականում կառավարում նստաշրջանը։
Երկու տեղամասեր BGP են հաստատում IPsec թունելի վրայով, սովորում են միմյանց նախադիրները, և դիագրամը վերանվանվում է ուղու կառավարում։ Հենց այդ պիտակն է շփոթության սկիզբը։ Նստաշրջանը իրոք փոխանակում է հասանելիություն և իրոք կիրառում է քաղաքականություն, բայց այն ձայն չունի, թե որ մատակարարը, մալուխը կամ երթուղիչն է տեղափոխում գաղտնագրված փաթեթները։ Ես տեսել եմ թիմ, որը վերակառուցում էր աշխատող թունել, քանի որ սպասում էր, թե BGP երթուղու փոփոխությունը տրաֆիկը կտեղափոխի մեկ այլ օպտիկամանրաթելային ուղի, որի վրա նստաշրջանը երբեք չէր կարող ազդել։
Ինչ են ենթադրում մարդիկ, թե նստաշրջանը ինչ է գնում
Սպասումների մեծ մասը գալիս է նրանից, թե ինչպիսին է երթուղու փոփոխությունը լաբորատորիայում։ Դուք հայտարարում եք նախադիր թունելի վրայով, հեռավոր կողմը տեղադրում է այն, և տրաֆիկը շարժվում է։ Նույն հաջորդականությունը տեղի է ունենում այն երթուղիչում, որն իրոք ունի տրաֆիկի ինժեներության լծակներ, ուստի երկուսը շփոթվում են։ Լաբորատորիայում երկու տեղամասերը սովորաբար կիսում են մեկ մուտքի կապ, և հենց դրա համար է, որ տարբերությունն այնտեղ երբեք չի երևում։
BGP-ն հասանելիության արձանագրություն է։ Այն ասում է գործընկերոջը, որ դուք կարող եք փաթեթներ հասցնել նախադիրի համար, և թույլ է տալիս յուրաքանչյուր կողմին դասավորել ստացված առաջարկները։ Դա իսկապես օգտակար է թունելի վրայով՝ նախադիրները հայտնվում և անհետանում են, երբ տեղամասերը գալիս ու գնում են, և դուք կարող եք մերժել մի միջակայք՝ առանց յուրաքանչյուր եզրային սարքում ստատիկ երթուղի գրելու։ Ինչ այն չի անում, դա մատակարարի երթուղիչները ձեր վերահսկողության տակ դնելն է։
Ստորին շերտը կրում է արտաքին վերնագիրը։ Ձեր թունելի վերջնակետը գաղտնագրված փաթեթներ է ուղարկում գործընկերոջ հասցեին, և այդ երկու հասցեների միջև ընկած ցանցը դրանք փոխանցում է այն երթուղիներով, որոնք տեղադրել են դրա օպերատորները։ BGP նստաշրջանում ոչինչ չի փոխում այդ որոշումը, եթե նույն մատակարարը չառաջարկի աջակցվող ծառայություն, որն անում է դա։
Ինչ է իրականում կրում նստաշրջանը
BGP խոսողը TCP կապ է բացում իր գործընկերոջ 179 պորտին՝ օգտագործելով RFC 4271-ում սահմանված հաղորդագրության ձևաչափերն ու ուղու ատրիբուտները։ Երբ գործընկերոջ հասցեն գտնվում է թունելի ներսում, թունելը պետք է բարձրացված լինի, և այդ հասցեն հասանելի լինի, մինչ նստաշրջանը նույնիսկ կսկսվի։ Ավարտված IKE փոխանակումը BGP հարևան չէ։ Երթուղու վրա հիմնված IPsec իրականացումները տրաֆիկը թողնում են միայն այն ժամանակ, երբ գոյություն ունի համապատասխան թունելային երթուղի, իսկ քաղաքականության վրա հիմնվածին անհրաժեշտ է գործընկերոջ հասցեն պաշտպանված ընտրիչի ներսում։ Սա հակառակ անելը ստեղծում է դասական վիճակը, երբ թունելը կանաչ է, իսկ նստաշրջանը պարապ նստած է։
Երբ նստաշրջանը բարձրացված է, քաղաքականությունը որոշում է, թե ինչն է անցնում դրա միջով։ Նախադիրների ցանկերը, AS-ուղու զտիչները, առավելագույն նախադիրների վերին սահմանը և լռելյայն երթուղիների վերաբերյալ հստակ որոշումը նվազագույնն են, և դրանք գործում են երկու ուղղություններով։ Գործընկերը, որն ընդունում է այն ամենը, ինչ ստանում է, կարող է ձեզ տալ լռելյայն երթուղի, որը լուռ փոխարինում է տեղական ինտերնետ հասանելիությունը։ Երկու ուղղություններին պետք են առանձին ցանկեր, որովհետև այն, ինչ ընդունում եք գործընկերոջից, և այն, ինչ հայտարարում եք նրան, տարբեր որոշումներ են։
router bgp 65010
neighbor 10.255.0.2 remote-as 65020
address-family ipv4 unicast
neighbor 10.255.0.2 prefix-list SITE-B-IN in
neighbor 10.255.0.2 prefix-list SITE-B-OUT out
neighbor 10.255.0.2 maximum-prefix 50
Այնուհետև կծում է MTU-ն։ Ինկապսուլյացիան փոքրացնում է օգտակար բեռը, ուստի մեծ թարմացումը կարող է կանգնեցնել նստաշրջան, որը թվում է կատարյալ հաստատված՝ գործընկերը մնում է վերևում, նախադիրները երբեք չեն հասնում, և ոչ մի ակնհայտ բան չի հայտնվում մատյանում։ Սահմանափակեք TCP MSS-ը թունելի ինտերֆեյսում, կամ սահմանեք թունելի MTU՝ տեղ թողնելով լրացուցիչ ծախսի համար, նախքան զտիչներին մեղադրելը։
Ուր են դեռ գնում արտաքին փաթեթները
Մի տեղամասից մյուսը գաղտնագրված փաթեթները դուրս են գալիս այն ճանապարհով, որը տեղական երթուղիչն ընտրում է գործընկերոջ հանրային հասցեի համար։ Եթե երկու տեղամասերը տրանզիտ են գնում նույն մատակարարից, անցնում են նույն մետրո օբյեկտով, կամ մի կողմը գտնվում է օպերատորի մակարդակի NAT-ի հետևում, թունելը մատակարարի խափանումից փրկվում է միայն պատահաբար։ Մոնիտորինգի գործիքում թունելների պատկերակները հաշվելը ձեզ ոչինչ չի ասում այդ մասին։
Երթուղու ընտրությունը և փոխանցման տեղադրումը նույնպես առանձին իրադարձություններ են։ Նախադիրը կարող է BGP աղյուսակում լինել որպես լավագույնը և այնուամենայնիվ բացակայել փոխանցման աղյուսակից, որովհետև հաջորդ ցատկը լուծելի չէ, կամ հաղթում է ավելի կոնկրետ երթուղի։ Երբ ինչ-որ մեկը հայտնում է, որ BGP-ն սովորել է նախադիրը, բայց տրաֆիկը չի հոսում, օգտակար հարցն այն է՝ արդյոք այն տեղադրված է և որ հաջորդ ցատկին է մատնանշում։
Դիզայնի վերանայման համար ազնիվ պատասխանը ընդհանուր կախվածությունների ցանկն է՝ մուտքի շղթա, վերին մատակարար, օբյեկտ և ցանկացած վիճակ պահող սարք վերադարձի ուղու վրա։ Թունելի վրայով նստաշրջանը չի կարող հեռացնել կախվածություն, որի վրա ինքը չի նստում։
Առանձնացնելու արժանի երեք որոշում
Երբ դիզայնը խառնում է դրանք, յուրաքանչյուր խափանման զրույց պտտվում է շրջանով։ Նախ թղթի վրա առանձնացրեք դրանք, ապա յուրաքանչյուրը կապեք այն սարքին, որն իրականում կիրառում է այն։
| Decision | Who controls it | Typical failure |
|---|---|---|
| Which prefixes may cross the relationship? | Both sides, through prefix and AS-path policy you configure deliberately | A default route accepted by mistake, or a vague aggregate |
| Which overlay next hop wins? | Local BGP selection plus next-hop resolution on your own routers | Prefix learned, never installed in the forwarding table |
| Where do the encrypted packets travel? | The underlay operators, unless a supported service adds real control | Path diversity that was never there |
Յուրաքանչյուր տող ունի տարբեր սեփականատեր։ Առաջինը բանակցություն է, երկրորդը՝ ձեր սարքերի կոնֆիգուրացիան, երրորդը՝ հիմնականում ուրիշի ցանցը։ Փոփոխության հայտը, որը նշում է իրեն դիպչող տողը, շատ ավելի հեշտ է հաստատել, քան այն, որն ասում է BGP խնդիր։
Ծրագրավորելու արժանի խափանման ռեժիմներ
Գործընկերոջ ամփոփիչ երթուղին ընդունելը ամենատարածված ինքնահասցեական վերքն է։ Ինչ-որ մեկը հայտարարում է կարճ ագրեգատ՝ փոխանակումը պարզեցնելու համար, հեռավոր կողմը ընդունում է այն, և թունելի հետևում չգտնվող միջակայքերի տրաֆիկը հետևում է թունելին ու մահանում։ Զտեք ճշգրիտ սպասվող նախադիրներով, կամ օգտագործեք ճիշտ սահմաններով նախադիրների ցանկ, և երբեք մի ընդունեք մերկ ագրեգատ, որովհետև այն նստաշրջանը կոկիկ է ցույց տալիս։
Հետ կանչելու ժամանակը երկրորդն է։ Հայտնաբերումը կախված է պահման ժամաչափերից, BFD-ից, եթե միացրել եք, թունելի մեռած գործընկերոջ հայտնաբերումից և նրանից, թե որքան արագ է հեռավոր կողմը դադարում հայտարարել։ Գոյություն ունեցող նստաշրջանները առանձին խնդիր են՝ նոր երթուղին կարող է վերականգնել նոր կապեր, մինչ հաստատված TCP նստաշրջանները շարունակում են օգտագործել հնացած հասցեներ, և ուղու վրա գտնվող վիճակ պահող հրաբորբերք կամ NAT կարող են պահել գրառումներ, որոնք այլևս չեն համապատասխանում։ Դրեք հավելվածի վերականգնումը ընդունման չափանիշների մեջ՝ փոխարենը ենթադրելու, որ երթուղու փոփոխությունը լուծում է ամեն ինչ։
Երրորդը վերադարձի ուղու ասիմետրիան է։ Տրաֆիկը կարող է ժամանել թունելով և վերադառնալ մատակարարի կապով, որը երբեք նախատեսված չի եղել այն կրելու համար, ինչը դրսևորվում է որպես միակողմանի ձայն, ձախողված ձեռքսեղմումներ կամ պատասխանները գցող հրաբորբերք։ Ստուգեք երկու ուղղությունները առանձին։
Ինչ գրել պայմանագրում, և ինչպես ստուգել այն
Թույլատրված նախադիրները պահանջեք գրավոր՝ ով իրավասու է ստեղծել յուրաքանչյուր միջակայք, թույլատրվա՞ծ է լռելյայն երթուղի, և որ հասցեների ընտանիքներն է աջակցում թունելի ծառայությունը։ RFC 8212-ը բացահայտ ներմուծման և արտահանման քաղաքականությունը դարձրեց eBGP-ի ակնկալիք այն իրականացումներում, որոնք հետևում են դրան, ուստի գործընկերը, որը դեռ ապավինում է անուղղակի ամեն ինչ ընդունելու վարքագծին, արժանի է հարցման։
Այնուհետև ստուգեք սարքից, ոչ թե դիագրամից։ Օգտակար հրամաններ FRR ոճի երթուղիչներում՝
show bgp summary
show bgp ipv4 unicast 10.10.0.0/16
show bgp ipv4 unicast neighbors 10.255.0.2 advertised-routes
show ip route 10.10.0.0/16
Ավելացրեք երկու դիտարկում, որոնք երթուղային աղյուսակը չի կարող տալ ձեզ։ Գրավեք արտաքին ինտերֆեյսում՝ հաստատելու, թե ինկապսուլացված փաթեթներն իրականում որ հասցեն են թիրախավորում, օրինակ՝ tcpdump -ni eth0 udp port 51820 WireGuard թունելի համար, կամ ESP զտիչ IPsec-ի համար։ Այնուհետև հետևեք դեպի գործընկերոջ հանրային հասցեն և համեմատեք ցատկերը թունելի ներսում արված հետքի հետ և եթե երկուսն էլ հետևում են նույն մատակարարի շղթային, ձեր ավելորդությունը ապրում է երթուղային քաղաքականության մեջ, ոչ թե ցանցում։
Վերջում դիտավորյալ փորձարկեք հետ կանչումը։ Իջեցրեք թունելը սպասարկման պատուհանի ընթացքում, գրի առեք, թե որքան ժամանակ է նախադիրը մնում տեղադրված, ինչ է պատահում գոյություն ունեցող նստաշրջաններին, և արդյոք հեռավոր կողմը վերադառնում է մի երթուղու, որը դուք իսկապես կընդունեիք։ Այդ վարժությունը դիզայնի մասին ավելի շատ է ասում, քան ցանկացած դիագրամ։
Երթուղին թույլտվություն չէ։ Նախադիրները, որոնք դուք պայմանավորվում եք փոխանակել, ոչինչ չեն ասում այն մասին, թե որ օգտատերերը կարող են հասնել թունելի հետևում գտնվող որ ծառայությանը, ուստի պահեք նույնականացումը, թույլատրված ծառայությունները և հոսթերի հրաբորբերքը հենց այնտեղ, որտեղ էին։ Հասանելի գործընկերը նույնպես թույլտվություն չէ անսահմանափակ տրանզիտի կամ կամայական հասցեներ ստեղծելու համար, և այդպիսի լիազորությունը պատկանում է պայմանագրին՝ որպես առևտրային հարց, ոչ թե BGP քաղաքականության տողին։
- Անվանեք այն նախադիրները, որոնք յուրաքանչյուր կողմ կարող է ստեղծել, և նրանք, որոնք երբեք չպետք է ընդունի։
- Սահմանափակեք MSS-ը թունելում և հաստատեք, որ մեծ թարմացումներն իսկապես հասնում են։
- Թվարկեք ստորին շերտի ընդհանուր կախվածությունները, ոչ թե թունելների քանակը։
- Չափեք իրական հետ կանչում և նշեք, թե ինչ է անում հավելվածը։