GCP HA VPN: BGP նստաշրջանը կախված է Waiting for peer-ում, հասցեների զույգի փոխարկումը
Cloud VPN-ի BGP նստաշրջանը, որը կախված է Waiting for peer-ում, սովորաբար փոխել է թունելի և գործընկերոջ հասցեները։ Ստուգեք զույգը նախքան որևէ բան վերակառուցելը։
BGP նստաշրջանը, որը երբեք չի հասնում Established վիճակին Cloud VPN թունելում, սովորաբար երթուղավորման խնդիր չէ։ Դա լարերի խնդիր է: երկու հասցեներ, որոնք պետք է հայելային լինեն միմյանց, մուտքագրվել են սխալ հերթականությամբ, կամ առաջին թունելի զույգը կրկին օգտագործվել է երկրորդում։ Թունելն ինքը կարող է լիովին առողջ լինել, մինչ նստաշրջանը կանգնած է Waiting for peer-ում, քանի որ IPsec-ը և BGP-ն առանձին բանակցություններ են նույն երկու վերջնակետերի միջև։ Որոշեք, թե այդ երկուսից որն է կոտրված, նախքան որևէ բան վերակառուցելը։
Մեկ հարց լուծում է դեպքերի մեծ մասը: արդյո՞ք գործընկեր սարքը ընդհանրապես տեսնում է Cloud Router-ի հասցեն։
Թունելի վիճակը և նստաշրջանի վիճակը տարբեր ստուգումներ են
Սկզբում գալիս են IKE-ը և ESP-ն։ Եթե թունելը հաստատված չէ, դրա ներսում ոչինչ նշանակություն չունի, և BGP հասցեի քննարկումը վաղաժամ է։ Կարդացեք թունելի կարգավիճակը և մանրամասն կարգավիճակը, ապա երթուղիչի BGP գործընկերոջ կարգավիճակը նույն թունելի համար։
Թունելը, որը աշխատում է, մինչ նրա BGP գործընկերը անջատված է, սահմանափակում է խափանումը նստաշրջանով: գործընկերոջ հասցե, ASN կամ TCP 179, որը հասնում է ներքին հասցեին։ Թունելը աշխատում է, նստաշրջանը աշխատում է և դեռ ոչ մի երթուղի VPC-ում սա երրորդ դեպքն է։ Հասցեները փոխելը այնտեղ չի օգնի, քանի որ նստաշրջանն արդեն աշխատում է, և նախածանցը պարզապես չի հայտարարվում կամ չի նախընտրվում։ Այս երեք դեպքերն իրարից անջատ պահելը աշխատանքի մեծ մասն է։
Յուրաքանչյուր թունելի պետք է իր /30-ը՝ երկու ծայրերը լրացված
Յուրաքանչյուր HA VPN թունել ստանում է link-local /30 169.254.0.0/16-ից, մեկ հասցե Cloud Router-ի ինտերֆեյսին, մյուսը՝ ձեր գործընկերոջը։ Գործընկերոջ դաշտը պետք է նշի հեռավոր ծայրը, երբեք երթուղիչի սեփական հասցեն։
Երկու թունել նշանակում է երկու ինտերֆեյս Cloud Router-ում, յուրաքանչյուրը տարբեր /30-ով։ 0 թունելի զույգը 1 թունելում կրկին օգտագործելը այն սխալն է, որը կոկիկ է թվում ամփոփ աղյուսակում և մահանում OPEN փաթեթում։
| Tunnel | Router interface | Peer address | What a swap produces |
|---|---|---|---|
| tunnel 0 | 169.254.1.1/30 | 169.254.1.2 | OPEN sent to itself or to nothing; session waits |
| tunnel 1 | 169.254.1.5/30 | 169.254.1.6 | same failure on the second session |
| both | one pair reused | one address reused | one session up, the other never leaves waiting |
Զույգը կարդացեք երթուղիչի ռեսուրսից, ոչ թե կոնսոլի ամփոփումից։ Ամփոփումը գործընկերոջ հասցեն ցույց է տալիս սյունակում, որը հեշտ է սխալ կարդալ, և ինտերֆեյսի ipRange-ը գործընկերոջ peerIpAddress-ի հետ պետք է նկարագրեն մեկ /30-ի հակառակ ծայրերը։
Փոխարկումը սովորաբար տեղի է ունենում վերակառուցման ժամանակ
Զույգերը խաչվում են հենց թունելը վերակառուցելիս։ Հին թունելի գործընկերոջ հասցեն պատճենվում է նոր թունելի ինտերֆեյսի դաշտում, կամ նոր նստաշրջանը ուղղվում է նախորդ նստաշրջանի գործընկերոջը։ Ամեն դեպքում Cloud Router-ը OPEN փաթեթներ է ուղարկում հասցեի, որը հիմա ինքն է, կամ հասցեի, որի հետևում թունել չկա։
Գրի առեք զույգերը նախքան կոնսոլը բացելը: թունելի անուն, ինտերֆեյս, երթուղիչի հասցե, գործընկերոջ հասցե, գործընկերոջ ASN։ Ապա ստեղծեք երկու թունելները մեկ անցումով, որպեսզի երկրորդը չլրացվի առաջինի մնացորդներով։
Եվս երեք պատճառ, թե ինչու է նստաշրջանը սպասում
Առաջինը գործընկերոջ ASN-ն է: յուրաքանչյուր կողմ պետք է կազմաձևվի մյուս կողմի ASN-ով, և անհամապատասխանությունը հասնում է գործընկերոջը, բայց երբեք չի հաստատվում։ Երկրորդը գործընկերոջ սեփական հրային պատն է, որը պետք է թույլատրի TCP 179 թունելի ինտերֆեյսում; IKE կամ ESP կանոնը դա չի ծածկում։ Երրորդը գործընկերն է, որը պատասխանում է այլ աղբյուրի հասցեից, քան այն, որը կազմաձևված է որպես նրա հարևան։
Գործընկերոջ սեփական մատյանն է որոշիչը։ Եթե նրա BGP ամփոփումը չի թվարկում հարևան այդ հասցեի համար, փաթեթները չեն հասնում, և զույգը կամ ուղին սխալ են։ Եթե հարևանը գտնվում է Active կամ Connect վիճակում, փաթեթները հասնում են, և նստաշրջանի պարամետրերը չեն համընկնում։
Ստուգեք այն հերթականությամբ, որով անցնում են փաթեթները
Աշխատեք դեպի դուրս: թունելի կարգավիճակ, ապա երթուղիչի BGP գործընկերոջ կարգավիճակ, ապա գործընկերոջ BGP ամփոփում, ապա երթուղիները։ Եթե առաջին երկուսը առողջ են, դադարեցրեք Cloud VPN կողմի խմբագրումը և աշխատեք գործընկեր սարքի վրա։ Եթե երթուղիչը գործընկերոջը հաղորդում է որպես անջատված, և ձեր սարքը հարևան չունի, զույգը սխալ է կամ BGP պորտը զտված է։ Գործընկերոջ թունելի ինտերֆեյսում փաթեթների որսումը լուծում է դա մեկ հայացքով, որովհետև OPEN փաթեթները կա՛մ հասնում են այնտեղ, կա՛մ երբեք չեն հասնում։
gcloud compute routers get-status ROUTER --region=REGION հրամանը տպում է գործընկերոջ վիճակը այն հասցեի կողքին, որը նա օգտագործում է, և դա հենց այն զույգն է, որը պետք է համեմատեք։
Երբ նստաշրջանը հաստատվի, հաստատեք, որ սովորած նախածանցը հայտնվում է VPC-ի երթուղիների աղյուսակում, և որ յուրաքանչյուր կողմում մեկ հոսթ պատասխանում է։ Ապա գրի առեք վերջնական զույգերը թունելների անունների կողքին, որպեսզի հաջորդ վերակառուցումը սկսվի ստուգված աղյուսակից, այլ ոչ թե կոնսոլի ամփոփումից։