Cloud VPN-ի կարգավիճակ. նախ կարդացեք ռեսուրսի վիճակը, հետո IKE մատյանը

Cloud VPN թունելը միաժամանակ երկու կյանքի ցիկլ է վարում, և դրանք նույն ժամացույցի վրա չեն։ Ռեսուրսը պետք է տեղաբաշխվի և կարգավորվի, նախքան այն կկարողանա բանակցել, և դրանից հետո արձանագրությունն ունի IKE հաղորդագրությունների իր հաջորդականությունը։ Վիճակի դաշտը կարող է հաղորդել առաջինի մասին՝ ոչինչ օգտակար չասելով երկրորդի մասին։ Դրանք որպես մեկ բան կարդալը հենց այն ձևն է, որով բանալու անհամապատասխանությունը մեղադրվում է տրամադրման ուշացման մեջ։

Սկսեք մեկ թունելի օբյեկտով և մեկ ժամանակային պատուհանով։

Երկու կյանքի ցիկլ, մեկ թունելի օբյեկտ

Ռեսուրսի կյանքի ցիկլը մատակարարի կողմից թունելի նախապատրաստումն է՝ հասցեներ, կարգավորում, տարողություն։ Արձանագրության կյանքի ցիկլը սկսվում է, երբ երկու կողմերն ունեն բավարար կարգավորում IKE_SA_INIT, ապա IKE_AUTH, ապա զավակ անվտանգության ասոցիացիաներ փոխանակելու համար։ Առաջին փուլում գտնվող թունելը չի ձախողվել իսկության հաստատման մեջ, որովհետև իսկության հաստատումը դեռ չի փորձվել։

Հենց այդ տարբերությունն է ամբողջ խնդիրը։ Մնացած ամեն ինչ այն մասին է, թե ինչպես դիտարկել այն՝ առանց անկապ հաղորդագրությունները միաձուլելու։

Կարդացեք օբյեկտը, ոչ թե վահանակի ամփոփումը

API-ից խնդրեք միայն այն երկու դաշտերը, որոնք նշանակություն ունեն, և ուրիշ ոչինչ, որպեսզի պատասխանը մնա բավական փոքր՝ գիշերվա ժամը երեքին կարդալու համար. gcloud compute vpn-tunnels describe NAME --region REGION --format="yaml(status,detailedStatus)"։ status դաշտը նշում է կյանքի ցիկլի փուլը, և detailedStatus-ը կրում է դրան կապված ընթեռնելի պատճառը։ Ամբողջական կարգավորման արտահանումը պատասխանում է այլ հարցերի և ավելի դժվար է տոմսի մեջ տեղադրել։ Նման միայն-ընթերցման կանչերը չեն կարող փոխել թունելը, ինչը կարևոր է, քանի դեռ միջադեպը դեռ ակտիվ է։

Գրանցեք կանչի ժամանակի դրոշմը արժեքների կողքին, որովհետև երկու դաշտերն էլ շարժվում են։

ALLOCATING_RESOURCES-ը բանալու անհամապատասխանություն չէ

Երբ թունելը հաղորդում է ALLOCATING_RESOURCES, մատակարարը դեռ հավաքում է օբյեկտը։ Նախապես համօգտագործված բանալու անհամապատասխանությունը հնարավոր չէ դիտարկել այդ փուլում, և արգելափակված գործընկերոջ պորտը նույնքան ապացուցված չէ։ Ինչ կարող եք ստուգել՝ մանրամասն հաղորդագրությունն է, թե արդյոք նախագիծը և ծառայությունը առողջ տեսք ունեն, և թե արդյոք թունելի կարգավորումը բավական ամբողջական է, որպեսզի գործընկերոջը ընդհանրապես կարելի է կապվել։ Գաղտնիքը հիմա փոխարինելը փոխում է արժեք, որը երբեք չի փորձարկվել։

Սպասեք, որ վիճակը շարժվի, նախքան կարգավորման մասին եզրակացություն անելը։

ESTABLISHED-ը մուտքի ստուգումների սկիզբն է

Հաստատված թունելը նշանակում է, որ IKE-ն ավարտվել է, ոչ թե որ տրաֆիկը հոսում է։ Հաստատեք այն երթուղիները, որոնք կրում է թունելը, և որտեղ ներգրավված է Cloud Router, հաստատեք BGP նստաշրջանը և այն նախածանցերը, որոնք նա սովորել է։ Ապա փորձարկեք թույլատրված հավելվածային փոխանակում, որովհետև firewall-ի կանոնը կամ բացակայող երթուղին կարող է արգելափակել տրաֆիկը լիովին առողջ թունելով։ Դրանցից յուրաքանչյուրը առանձին դիտարկում է՝ առանձին ուղղումով։

Վիճակը ձեզ ասում է, թե հաջորդը որ հարցը տալ։ Այն երբեք ձեր փոխարեն չի պատասխանում մուտքի հարցին։

Կապեք մեկ օբյեկտ և մեկ ժամանակային պատուհան

Մատյանի հին իսկության ձախողումը պատկանում է ավելի վաղ փորձին, եթե դրա ժամանակի դրոշմը չի ընկնում ձեր ուսումնասիրած պատուհանի մեջ։ Քաշեք թունելի ռեսուրսի մատյանները նույն րոպեների համար, ինչ գրանցված վիճակը, և պահեք նույնացուցիչները միասին։ Ավելի ուշ IKE իրադարձությունը կարող է ցույց տալ, որ բանակցությունը սկսվել է, մինչ դուք նայում եք վահանակի արդեն հնացած հաղորդագրությանը։

Եթե թունելը վերականգնվում է նախքան որևէ բան հավաքելը, ասեք դա։ Չպարզված պատճառը ավելի լավ գրառում է, քան անկապ տողերից հավաքված ինքնավստահ պատմությունը։

Հաջորդ քայլը միշտ նույն ձևն ունի՝ մեկ օբյեկտ, մեկ պատուհան, մեկ փուլ։ Դրանից ավելի լայն ամեն ինչ ամփոփում է, ոչ ախտորոշում։