Cloud Run-ից դեպի տեղական VPN․ ուղիղ VPC ելքի կարգավորում

Թունելը աշխատում է, վիրտուալ մեքենան հասնում է տեղական սերվերին, իսկ Cloud Run ծառայությունը ժամկետանց է լինում նույն հոսթի վրա։ Սա այս առաջադրանքի սովորական մեկնարկային կետն է, և թունելը հազվադեպ է այն, ինչ սխալ է։ Cloud Run վերանայումը լռելյայն չի գտնվում ձեր VPC-ում, և երբ գտնվում է, այն օգտագործում է իր իսկ աղբյուրի հասցեները՝ ձեր արդեն երթուղավորած VM ենթացանցի փոխարեն։ Ստորև բերված runbook-ը միացնում է ծառայությունը, երթուղավորում նրա իրական աղբյուրի տիրույթը, ապա ապացուցում ուղին այն վերանայումից, որը սպասարկել է հարցումը։ Կատարեք այն այդ հերթականությամբ, որովհետև առաջին քայլը բաց թողնելն է պատճառը, որ այս դեպքերից շատերն ավարտվում են VPN փոփոխությամբ, որը ոչինչ չի ուղղում։

Միացրեք վերանայումը մինչև թունելի վրիբախտումը

Cloud Run-ը աջակցում է ուղիղ VPC ելքին, որը ծառայության թրաֆիկը տեղադրում է ձեր VPC-ի ենթացանցում՝ առանց Serverless VPC Access միակցիչի։ Գոյություն ունեցող ծառայության համար թարմացումը այսպիսի տեսք ունի․

gcloud run services update SERVICE \
  --region=REGION --network=NETWORK --subnet=SUBNET \
  --vpc-egress=private-ranges-only

Փոխարինեք տեղապահները, վերանայեք, թե տեղակայումը ինչ է անում ուղիղ թրաֆիկի հետ, և ընտրեք ենթացանց ծառայության տարածաշրջանում՝ բավարար հասցեային հզորությամբ և ճիշտ ցանցային թույլտվություններով։

Ընտրեք նպատակակետին համապատասխան ելքի ռեժիմը

private-ranges-only ուղարկում է այն նպատակակետերը, որոնք դասակարգում է որպես մասնավոր, VPC-ի միջով։ Սա չի նշանակում «այն ամենը, ինչ հասանելի է VPN-ով», և այդ բացը ի հայտ է գալիս, երբ տեղական ծառայությունը գտնվում է տիրույթում, որը կարգավորումն այդպես չի դասակարգում։ Եթե նպատակակետը ծածկված չէ, ապա all-traffic փաստագրված մյուս ռեժիմն է, և այն ամեն ինչ ուղարկում է VPC-ի միջով՝ ներառյալ ծառայության հանրային կախվածությունները։ Ընտրեք գիտակցաբար և հետևանքը գրեք փոփոխության գրանցամատյանում։

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

Երթուղավորեք Cloud Run-ի աղբյուրը, ոչ թե VM-ի աղբյուրը

Ուղիղ VPC ելքը ժամանակավոր հասցեներ է հատկացնում ընտրված ենթացանցից, և տեղական կողմը պետք է թրաֆիկը վերադարձնի այդ տիրույթ։ Այլ VM ենթացանցի համար գրված վերադարձի ուղի կամ firewall-ի թույլտվություն դիագրամում ճիշտ կթվա և գործնականում կձախողվի։ Վերցրեք ենթացանցի CIDR-ը VPC-ից, ոչ թե հիշողությունից, ապա հաստատեք, որ հեռավոր սարքի crypto ACL-ը կամ երթուղային աղյուսակը ներառում է այն։

Դինամիկ երթուղավորման դեպքում ստուգեք, թե Cloud Router-ը իրականում ինչ է հայտարարում և ինչ է ներմուծում VPC-ն՝ ներառյալ ցանկացած հատուկ հայտարարության քաղաքականություն։ Կոնսոլում գոյություն ունեցող, բայց այս նպատակակետի համար չընտրված ուղին նույնն է, ինչ ուղու բացակայությունը։

Երեք պայման, որոնք բոլորը պետք է պահպանվեն

Աշխատող ուղին պահանջում է հետևյալը, և նրանցից յուրաքանչյուրը ձախողվում է յուրովի․

• Ուղի VPC-ում դեպի տեղական նախածանցը նախատեսված Cloud VPN կապի միջով։
• Հակադարձ ուղի տեղական կողմում Cloud Run ենթացանցի համար։
• Firewall-ի և IPsec-ի պաշտպանության շրջանակ, որը թույլ է տալիս աղբյուրը, նպատակակետը և պորտը։

Բացակայող ուղին սովորաբար թվում է ժամկետանց՝ առանց հեռավոր կողմի որևէ ապացույցի։ Հակադարձ ուղու խնդիրը թվում է հարցում, որը հասնում է, և պատասխան, որը անհետանում է։ Firewall-ի կամ ընտրիչի խնդիրը կարող է թվալ մերժում կամ լուռ կորուստ՝ կախված սարքից։ Պարզելը, թե երեքից որն ունեք, զգալիորեն նեղացնում է հաջորդ հրամանը։

Չավելացրեք մեկ ժամանակավոր Cloud Run հասցե թույլատրվածների ցանկում։ Օգտագործեք ենթացանցի տիրույթը և հավելվածին համապատասխան լիազորման ձևավորում։

Փորձարկեք այն վերանայումը, որը սպասարկել է հարցումը

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

Սպասեք Direct VPC-ի մեկնարկային կապի փաստագրված ուշացումներին և տվեք հաճախորդին պատրաստության կամ կրկնափորձի ռազմավարություն՝ յուրաքանչյուր սառը մեկնարկը կոտրված թունել ախտորոշելու փոխարեն։

Հետադարձ և ինչ այս չի անում

Հետադարձելու համար վերականգնեք ծառայության ցանցային և ելքի կարգավորումները նրանց նախորդ արժեքներին և հաստատեք, որ ավելի վաղ վերանայումը դեռ սպասարկում է թրաֆիկը։ Պահեք gcloud հրամանը փոփոխության գրանցամատյանում, որովհետև մասնակի փոփոխության հակառակը վեց շաբաթ անց ակնհայտ չէ։ VPC կապը հանելը ծառայությունը վերադարձնում է իր նախորդ ելքի ուղուն, ինչը կարող է հենց այն լինել, ինչ ուզում եք միջադեպի ընթացքում։

Այս ձևավորումը ծածկում է Cloud Run-ի սկսած կապերը և դրանց պատասխանները։ Այն տեղական ցանցին չի տալիս հասցեավորելի socket ծառայության ներսում, որովհետև ներս ընկած ազդեցությունը ingress որոշում է։