Cloud VPN-ի BGP հասցեները պատկանում են թունելի ներսին, ոչ թե ցանցային քարտին

Բացեք VPN-ի Cloud Router էջը, և ձեզ է նայում 169.254.0.0/16-ի սահմաններում հասցեով BGP նստաշրջան։ Բնական արձագանքը այդ հասցեն VM-ի վրա ինչ-որ տեղ դնելն ու նստաշրջանի բարձրանալուն սպասելն է։ Այդ արձագանքը սխալ է կոնկրետ ձևով. զույգը պատկանում է այն տրամաբանական կապին, որը ստեղծում է IPsec թունելը, ոչ թե մեքենայի սովորական ցանցային ինտերֆեյսին։ Ոչինչ, ինչ ավելացնեք NIC-ին, չի ստիպի թունելին կրել BGP։

Հետևեք զույգին դեպի ներքև փաթեթակույտում՝ փոխարենը այն հոսթին ավելացնելու։

Սկսեք այնտեղ, որտեղ կոնսոլը ցույց է տալիս զույգը

Նստաշրջանի էջը թվարկում է Cloud Router-ի BGP հասցե և զուգընկերոջ հասցե, երկուսն էլ link-local են IPv4 HA VPN-ի համար։ Դրանց կողքին արտաքին դարպասների հասցեներն են, որոնք ավարտում են թունելները։ Դրանք տարբեր օբյեկտներ են. link-local զույգը ապրում է ներսում, իսկ դարպասների հասցեները՝ դրսում և պետք է լինեն երթուղելի, նախքան որևէ այլ բան կաշխատի։

Գրեք բոլոր երեքը՝ նախքան կոնֆիգուրացիայի ֆայլը բացելը, որովհետև դրանք իրար խառնելը հենց ամբողջ ձախողման եղանակն է։

Իջեք այն թունելի մոտ, որը կրում է այն

link-local զույգը նշանակություն է ստանում միայն այն դեպքում, երբ երկու դարպասների միջև գոյություն ունի IPsec անվտանգության ասոցիացիա։ Google-ի կողմում HA VPN թունելները ստեղծում են այն երկու ինտերֆեյսների վրա. ձեր կողմում դա այն է, ինչ բանակցել է զուգընկերը։ Նախ ստուգեք տվյալների ասոցիացիան swanctl --list-sas-ով և նշեք, թե որ թունելն է վերև որ ինտերֆեյսում, որովհետև մեռած թունելի վրա առողջ BGP նստաշրջան անհնար է, իսկ հույսով լցված կոնֆիգուրացիայով մեռած թունելը սովորական երևույթ է։

BGP փաթեթը ներքին IP երթևեկություն է։ Արտաքին ցանցը այն երբեք չի տեսնում, ուստի ոչ մի կոմուտատորի պետք չեն երկու հասցեները մեկ VLAN-ի վրա։

Այժմ կարգավորեք Linux զուգընկերոջը համապատասխանելու համար

Ընտրեք աջակցվող թունելի ձևավորումը և թողեք այն որոշի ներքին հասցեները։ Երթուղային ինտերֆեյսի դեպքում երթուղու գրառումը և բանակցված երթևեկության ընտրիչները պետք է համաձայնեն, որովհետև միայն ինտերֆեյսի անունը ոչինչ չի թույլատրում։ Ուղղեք BIRD-ը դեպի ներքին տեղական հասցեն և Cloud Router-ի ներքին հասցեն, սահմանեք AS համարները նստաշրջանի էջից և թույլատրեք TCP 179-ը պաշտպանված ուղու ներսում։ Պահեք հեռավոր արտաքին հասցեի երթուղին ֆիզիկական uplink-ի վրա, որպեսզի թունելը չորսալ իր սեփական տրանսպորտը։

Թունելը, որն ինքն իրեն երթուղավորում է, ձեռքսեղմումով օղակ է, և մեկ ժամ այն կթվա որպես հրային պատի խնդիր։

Ստուգեք յուրաքանչյուր փուլ հերթականությամբ, ոչ թե ամբողջը միանգամից

Անցեք փուլերը. անվտանգության ասոցիացիան վերև, ներքին զուգընկերը հասանելի թունելի հասցեից, BGP նստաշրջանը հաստատված, նախածանցերը ընդունված, ապա աշխատանքային բեռի նախածանցը իրականում օգտագործված։ birdc show protocols-ը պատասխանում է երրորդ հարցին և ոչ այլ ինչի, այդ իսկ պատճառով մարդիկ վաղ են հաղթանակ հայտարարում։

Հաստատված հարևանը չի խոստանում, որ երկու կողմերն էլ հայտարարել են ձեզ անհրաժեշտ նախածանցերը, կամ որ այդ երթուղիները տեղադրվել են որպես նախընտրելի։

Եթե նստաշրջանը հաստատված է, իսկ երթևեկությունը դեռ գնում է սխալ ուղով, համեմատեք հայտարարված նախածանցները նրա հետ, ինչ անում է երթուղային աղյուսակը դրանցով. Ավելի կոնկրետ երթուղին այլ տեղ, կամ նախապատվությունը այլ ուղուն, ձեզ տալիս է աշխատող BGP նստաշրջան և ոչ մի օգտակար փոխանցում։

Կանգ առեք, նախքան սա Router Appliance-ի վրա կիրառելը

Network Connectivity Center Router Appliance-ը տարբեր միացման մոդել է։ Նրա Cloud Router զուգընկերներն օգտագործում են ներքին հասցեներ VPC-ի և ենթացանցի դասավորությունից, ոչ թե HA VPN-ի link-local զույգից։ Եթե իրական նպատակը BGP-ն է երթուղավորող VM-ի հետ, հետևեք այդ արտադրանքի ինտերֆեյսի պահանջներին՝ link-local նստաշրջան պատճենելու փոխարեն։

link-local շրջանակը դեռ նշանակում է այն, ինչ ասում է։ Տրամաբանական թունելը տրամադրում է այս հարևանությունը, և այն չի լիցենզավորում կամայական link-local նպատակակետերի երթուղավորումը VPC-ով։