Google HA VPN-ը Cisco երթուղիչին. նախ պլանավորեք գործընկերոջ ռեսուրսը
Անվանեք Google-ի երկու ինտերֆեյսները, գործընկերոջ ռեսուրսը, IKEv2 պայմանագիրը և յուրաքանչյուր BGP նստաշրջան նախքան Cisco երթուղիչը կարգավորելը, ապա ընտրեք մեկ գործընկեր կամ երկու։
Cisco-ից Google HA VPN-ում առաջին որոշումը ոչ թե այն է, թե որ կրիպտո պրոֆիլն օգտագործել, այլ այն, թե մեկ տեղական սարքը, թե երկուսը կավարտեն թունելները։ Google-ի HA VPN դարպասն ունի երկու ինտերֆեյս, և յուրաքանչյուրը սպասում է համապատասխան գործընկերոջ թունելի։ Դա ձեզ տալիս է երկու թունել՝ անկախ նրանից՝ ունեք երկու երթուղիչ, թե ոչ, և տարբերությունը նրանում է, թե արդյոք մեկ սնուցման աղբյուրը կամ ծրագրային թարմացումը կարող է տապալել ամբողջ նախագիծը։
Որոշումը մեկ գործընկեր սարք է, թե երկու
Ընտրեք դասավորությունը երեք պայմանների հիման վրա՝ կարող եք արդյոք ընդունել տեղական խափանման կետ, արդյոք պետք է օգտագործել երկու ամպային ինտերֆեյսը, և որքան վերահամընկնում են հանդուրժում ձեր աշխատանքային բեռները։ Եթե երեքից որևէ մեկը խիստ պահանջ է, երկու գործընկեր սարքերը ազնիվ պատասխանն են։
Որոշեք դա նախքան կոնսոլ բացելը, քանի որ պատասխանը փոխում է, թե քանի թունել և BGP նստաշրջան պետք է նկարագրի աշխատաթերթը։
Գրեք աշխատաթերթը ցանկացած հրամանից առաջ
Աշխատաթերթն ունի հինգ տող, և յուրաքանչյուրին պետք է սեփականատեր։
| Row | What it records |
|---|---|
| Google side | Project, VPC, region, HA VPN gateway, and the external address of each interface |
| Peer side | The Cisco external addresses, plus the external peer VPN gateway resource that represents them |
| Tunnel pairs | Which peer interface maps to each Google interface, with IKE version, secret and crypto parameters |
| Routing | Cloud Router, local and remote AS numbers, and one inside BGP pair per tunnel |
| Workloads | Approved on-premises and VPC prefixes, and what firewall policy should permit between them |
Արտաքին գործընկերոջ ռեսուրսը նկարագրում է ձեր ինտերֆեյսները Google Cloud-ի ներսում, և դրա ստեղծումը չի կարգավորում Cisco երթուղիչը։ Այդ ասիմետրիան զարմացնում է նրանց, ովքեր սպասում են, որ ամպային կոնսոլը կլինի ճշմարտության աղբյուրը երկու ծայրերի համար։ Դա հայտարարություն է այն մասին, թե ինչ պետք է սպասի Google-ը, և երթուղիչը դեռ պետք է համապատասխանի դրան։ Google-ի գործընկերոջ դարպասի ուղեցույցը այդ հայտարարությունը քարտեզագրում է թունելի, BGP-ի, ֆայրվոլի և IKE-ի այն աշխատանքին, որը դեռ պարտք եք։
Եթե տողը սեփականատեր չունի, այն կլրացնի նա, ով հերթապահ է անցման ընթացքում։
Առանձին պահեք հասցեի երեք դերերը
Հանրային գործընկերոջ հասցեները կրում են արտաքին IPsec փոխանակումը։ Ներքին BGP զույգը պատկանում է դրա վրայով անցնող պաշտպանված տրամաբանական կապին։ Հայտարարված LAN և VPC նախածանցերը նկարագրում են այդ կապի հետևում գտնվող աշխատանքային բեռները։ VM-ի ներքին հասցեն արտաքին գործընկերոջ դաշտում պատճենելը խառնում է առաջին երկու դերերը, և խափանումը նման է բանակցային խնդրի, այլ ոչ թե տվյալների մուտքագրման սխալի։
Պլանավորեք երկու համապատասխան գործընկերոջ թունել՝ մեկը յուրաքանչյուր HA VPN ինտերֆեյսի համար։ Երկու ամպային ինտերֆեյսի օգտագործումն ինքնին չի վերացնում տեղական խափանման կետը, քանի որ երկու թունելները դեռ կարող են վայրէջք կատարել նույն շասսիի վրա։
Գրեք հասցեի դերը աշխատաթերթի յուրաքանչյուր արժեքի կողքին։ Այդ մեկ սովորությունը կանխում է խառնուրդի մեծ մասը։
Թարգմանեք աշխատաթերթը Cisco թողարկման
Սկսեք աջակցվող գործընկերոջ փաստաթղթերից կամ ձեր պլատֆորմի համար համապատասխան Google կոնֆիգուրացիայի ձևանմուշից, ապա համաձայնեցրեք յուրաքանչյուր տեղապահ աշխատաթերթի հետ։ Ստուգեք IKEv2 նույնականացումը, ESP առաջարկները, PFS-ը և թունելի ու երթուղավորման մոդելը միասին, քանի որ դրանցից մեկում անհամապատասխանությունը սովորաբար ի հայտ է գալիս որպես անհամապատասխանություն մյուսում։ Օգտագործեք իրական պլատֆորմը և ծրագրային թողարկումը՝ ընտրելու համար, թե ինչ է աջակցվում, քանի որ Classic VPN բաղադրատոմսը տարբեր մեկնարկային կետ է։
Հեռու պահեք ընդհանուր գաղտնիքը էկրանի նկարներից, տոմսերի կցորդներից և աջակցության նշումներից։ Դեպքի մեկնաբանության մեջ փակցված նախապես համօգտագործված բանալին հավատարմագրերի բացահայտում է, ոչ թե խնդիրների լուծման արտեֆակտ։
Եթե ձևանմուշը և աշխատաթերթը չեն համընկնում, կանգ առեք և լուծեք այն թղթի վրա։ Սարքը ձեր փոխարեն չի արբիտրաժ անի։
Ընդունեք յուրաքանչյուր թունել իր իսկ ապացույցներով
HA VPN-ին պետք են BGP նստաշրջաններ, և հաջող IKE բանակցությունը հաստատում է միայն առաջին փուլը։ Ներքին նստաշրջանը պետք է բարձրանա, նախատեսված նախածանցերը պետք է հայտարարվեն և ընդունվեն, և օգտակար երթուղիները գումարած ֆայրվոլի թույլտվությունները պետք է գոյություն ունենան նախքան աշխատանքային բեռի երթևեկությունը կշարժվի։ Այդ ամենը որպես մեկ կանաչ լույս գրանցելը թաքցնում է, թե որ փուլն է իրականում ձախողվել։
Գրանցեք ընդունման ապացույցները յուրաքանչյուր թունելի համար՝ բանակցված անվտանգության միավորումներ, BGP հարևանի վիճակ, սպասվող սովորած նախածանցեր և նախատեսված աշխատանքային բեռի ուղի։ Այնուհետև անցկացրեք վերահսկվող խափանման և վերականգնման ստուգում, քանի որ թունելը, որը երբեք չի ձախողվել, այն թունելն է, որի վերականգնման ուղին չի փորձարկվել։
Այդ գրառումը կրկին օգտագործելի է հաջորդ անգամ, երբ նախագիծը փոխվի, և դա է տարբերությունը փոխգործակցության և մի հրամանի բեկորի միջև, որի ենթադրությունները կորել են։