GCP Classic VPN-ը Terraform-ում. դարձրեք թունելը երթուղային

Classic VPN-ում պիտակը չի որոշում վարքը։ Երթուղային նշանակում է տեղական սելեկտոր 0.0.0.0/0, համապատասխան հեռավոր սելեկտորներ և բացահայտ երթուղի։

Պլանը մաքուր է կիրառվում, թունելը բարձրանում է, և կոնսոլը այն անվանում է քաղաքականության վրա հիմնված։ Երթևեկությունը դեռ չի անցնում, և Terraform ռեսուրսում երթուղային անջատիչի որոնումը ոչ մի տեղ չի հասնում, քանի որ այդպիսի դաշտ գոյություն չունի։ Classic VPN-ում երթուղային վարքը ռեժիմ չէ, որ դուք ընտրում եք։ Սա այն է, ինչ ստանում եք, երբ տեղական երթևեկության սելեկտորը 0.0.0.0/0 է, հեռավոր սելեկտորները թվարկում են այն ցանցերը, որոնք իրականում ուզում եք, և երթուղին մատնանշում է թունելը։ Երեք բան, և պիտակը հետևում է։

Թունելի ռեժիմի դաշտի առասպելը

Կոնսոլի պիտակը արտացոլում է այն, ինչ API-ն տեսնում է սելեկտորներում։ Ռեսուրսում ոչինչ չի ասում երթուղային, ուստի ոչինչ չկա ճշմարիտ արժեքի վրա դնելու։

Այդ դաշտի որոնումը խլում է խնդրի առաջին ժամը, մինչդեռ սելեկտորների արժեքները կարդալը տևում է վերջին հինգ րոպեն։

Ինչ է նշանակում երթուղային այստեղ

Google-ը Classic VPN-ի երթուղային թունելները փաստաթղթավորում է որպես քաղաքականության վրա հիմնված թունելներ, որոնց տեղական սելեկտորը 0.0.0.0/0 է։ Միայն հեռավոր միջակայքերն են անվանվում, և տեղական կողմը դիտվում է որպես ցանկացած հասցե։ Այդ պատճառով ձեր կոնֆիգուրացիայի նշիչը արժեք է, ոչ թե ռեժիմ։ Գրեք երկու սելեկտորներն էլ բացահայտ և կարդացեք դրանք պլանի ելքում:

local_traffic_selector  = ["0.0.0.0/0"]
remote_traffic_selector = ["10.20.0.0/16"]

Այդ հատվածում զուգընկերոջ նախածանցը օրինակելի է՝ կարևորը ձևն է։

Երթուղին առանձին օբյեկտ է

Թունելի օբյեկտը երթուղի չի տեղադրում։ Փաթեթները կարող են համապատասխանել թունելի քաղաքականությանը և այնուամենայնիվ տեղ չունենալ գնալու, քանի որ հաջորդ ցատկը որոշում է VPC-ի երթուղային աղյուսակը։ Երթուղուն անհրաժեշտ են նպատակակետ միջակայքը, ցանցը, թունելը որպես հաջորդ ցատկ և առաջնահերթություն, որը հաղթում է ցանկացած ավելի լայն բանի։ Եթե մոռանաք այդ մասին, կստանաք թունել, որը հաղորդում է կապ հաստատված, և ստուգում, որը երբեք չի լքում VPC-ն։

resource "google_compute_route" "office" {
  name                = "office-via-vpn"
  dest_range          = "10.20.0.0/16"
  network             = google_compute_network.vpc.name
  next_hop_vpn_tunnel = google_compute_vpn_tunnel.to_office.id
  priority            = 1000
}

Ստեղծեք երթուղին նույն մոդուլում, ինչ թունելը, որպեսզի երկուսը վերանայման ժամանակ չհեռանան իրարից։

Արտացոլեք սելեկտորները զուգընկերոջ վրա

Հեռավոր սարքը պետք է կարգավորվի հայելային պատկերով՝ նրա տեղական միջակայքը ձեր հեռավոր սելեկտորն է, և նրա հեռավոր միջակայքը պետք է ծածկի այն GCP ենթացանցերը, որոնք ակնկալում եք օգտագործել։ Եթե կողմերից որևէ մեկը նեղանա, 2-րդ փուլը ձախողվում է, թեև 1-ին փուլը հաջողվում է։ Սա կոնֆիգուրացիայի ամենատարածված ձևն է, որը կոնսոլում ճիշտ է թվում և երթևեկություն չի տանում։

Փոփոխության վերանայման ընթացքում տպեք երկու կողմերի սելեկտորները կողք կողքի։

Բաժանեք ստատիկ հասցեն երկու կիրառման

Պահված հասցեի և դրան հղվող թունելի ստեղծումը մեկ կիրառմամբ անկայունության հայտնի աղբյուր է, քանի որ հասցեն պետք է գոյություն ունենա նախքան փոխանցման կանոնը կկարողանա օգտագործել այն։ Նախ կիրառեք միայն հասցեի ռեսուրսը, ապա ավելացրեք դարպասը, փոխանցման կանոնները և թունելը և կիրառեք նորից։ Terraform-ը երկրորդ գործարկման ժամանակ կարդում է գոյություն ունեցող հասցեն վիճակից և նորից օգտագործում այն։ Եթե բաց թողնեք դա, թունելը կարող է յուրաքանչյուր կիրառման ժամանակ նոր հանրային հասցե ստանալ, ինչը ամեն անգամ կոտրում է զուգընկերոջ կոնֆիգուրացիան։

Երկու կիրառում հիմա ավելի էժան է, քան յուրաքանչյուր թողարկման ժամանակ զուգընկերոջ փոփոխությունը։

Ստուգեք բանակցությունը, ոչ թե պիտակը

Կիրառելուց հետո ստուգեք երեք առանձին փաստ՝ թունելը հաղորդում է կապ հաստատված, երթուղին գոյություն ունի նախատեսված հաջորդ ցատկով, և զուգընկերը հաղորդում է, որ և 1-ին, և 2-րդ փուլերը բարձր են։

Թունելը բարձր է, բայց 2-րդ փուլը ցածր, ինչը նշանակում է, որ երկու կողմերը համաձայն չեն սելեկտորների շուրջ:

  • Մի կողմը թվարկում է ենթացանց, որը մյուսը չի թվարկում։
  • Մի կողմը օգտագործում է ագրեգատ, որը մյուսը նեղացրել է։
  • Երթուղին գոյություն ունի, բայց մատնանշում է այլ թունել։

Classic VPN-ը մեկ թունել է՝ ավելի ցածր SLA-ով, քան HA VPN-ը, իսկ HA VPN-ը օգտագործում է երկու ինտերֆեյս, երկու թունել և BGP՝ տարբեր ռեսուրսային տիպերով։ Դասական օրինակը HA կոնֆիգուրացիայի մեջ պատճենելը և սպասելը, որ սելեկտորի դաշտերը նույն կերպ կվարվեն, առանձին սխալ է, որից արժե խուսափել։ Թունելի դաշտերն իրենք փաստաթղթավորված են google_compute_vpn_tunnel-ի տեղեկանքում։

Առնչվող հոդվածներ