App Engine-ը կարող է հասնել ձեր VPN տվյալների բազային՝ ինչ պետք է համընկնի

Այն պնդումը, որ App Engine Standard-ը չի կարող հասնել մասնավոր տվյալների բազային Cloud VPN-ի միջոցով, պլատֆորմի ավելի վաղ սերնդի մնացորդ է: Standard-ի օրինակները չեն ստանում VPC-ին բնորոշ հասցե, ինչպես որոշ այլ գործարկման միջավայրեր, բայց կարող են egress ուղարկել ձեր ցանցում գտնվող Serverless VPC Access կցորդի միջոցով: Երբ այդ ուղին գոյություն ունի, Cloud VPN-ը և հեռավոր firewall-ը կցորդի երթևեկությունը տեսնում են ինչպես ցանկացած այլ աղբյուր: Այն, ինչ ձախողվում է, հազվադեպ է ինքը՝ հնարավորությունը: Սա այն երեք կարգավորումներից մեկն է, որոնք երբեք չեն հավասարեցվել:

Որտեղից է եկել հին պատասխանը

Մինչ կցորդների գոյությունը, գործնական պատասխանն իրոք այն էր, որ Standard-ը կարող էր խոսել միայն հանրային վերջնակետերի հետ, և թիմերը տեղափոխվում էին proxy VM կամ այլ գործարկման միջավայր՝ դա շրջանցելու համար: Պլատֆորմը փոխվեց, ժողովրդական իմաստությունը՝ ոչ: Առցանց շատ խորհուրդներ դեռ արտացոլում են այն դարաշրջանը, երբ egress-ի տարբերակ ընդհանրապես չկար:

Ուղղումը ավելի նեղ է, քան հնչում է: Standard-ը կարող է հասնել մասնավոր ցանցին, բայց միայն աջակցվող egress ինտեգրման միջոցով և միայն այն նշանակակետերի համար, որոնք այդ ինտեգրումը իրոք որսում է:

Նախ ընտրեք egress-ի ուղին

Ծառայությանը կցված կցորդն է, որ նրա երթևեկությունը դնում է VPC-ի մեջ: Կցորդի փաստաթղթերը թվարկում են տարածաշրջանային նախապայմանը և egress-ի կարգավորումները. կցորդը պետք է գոյություն ունենա ծառայության տարածաշրջանում և օգտագործելի լինի տեղակայող ինքնության համար:

vpc_access_connector:
  name: projects/PROJECT_ID/locations/REGION/connectors/CONNECTOR_NAME
  egress_setting: private-ranges-only

private-ranges-only-ը մասնավոր նշանակակետերը ուղարկում է VPC, իսկ մնացած ամեն ինչ թողնում է սովորական ինտերնետի ուղուն, ինչը սովորաբար այն է, ինչ պետք է տվյալների բազայի միացմանը: all-traffic-ը ելքային երթևեկությունը լայնորեն մղում է VPC-ի միջով, ուստի սովորական ինտերնետ կանչերը նույնպես ժառանգում են VPC-ի NAT-ը և firewall-ի դիրքը:

Ֆայլը տեղում խմբագրելը ոչինչ չի փոխում, մինչև չտեղակայեք: Աշխատող տարբերակը պահպանում է այն կոնֆիգուրացիան, որով ստեղծվել է:

Աղբյուրի հասցեն կցորդն է, ոչ ձեր նոթբուքը

Այստեղ է գնում վրիպազերծման ժամանակի մեծ մասը: Հեռավոր VPN դարպասը և տվյալների բազայի firewall-ը պետք է VPC-ի ներսում ընդունեն կցորդին հատկացված միջակայքը, ոչ ձեր գրասենյակի հասցեն և ոչ ծառայության հանրային egress հասցեն: Մեկ կանոն գրելուց առաջ այդ միջակայքը փնտրեք կոնսոլում:

Եվս երկու տեղ պետք է համաձայնվի: VPC-ի երթուղային աղյուսակին պետք է երթուղի դեպի հեռավոր տվյալների բազայի ցանց, իսկ հեռավոր կողմին՝ վերադարձի երթուղի կցորդի միջակայքի համար: Եթե թունելը օգտագործում է երթևեկության ընտրիչներ, հաստատեք, որ կցորդի միջակայքը գտնվում է բանակցված սահմաններում: Երթուղին, որը գոյություն ունի միայն հեռավորից տեղական ուղղությամբ, տարածված բացթողում է, և այն բաց է թողնում ping-երը՝ երբեք չավարտելով TCP ձեռքսեղմումը:

Թունելը, որն ընդունում է միայն VM ենթացանց, կցորդի փաթեթները կթափի առանց օգտակար սխալի հաղորդագրության, և դրա համար է, որ տվյալների բազայի ժամկետի սպառումը նման է հավատարմագրերի խնդրի:

DNS-ը ճանապարհորդում է այլ ուղով

Մասնավոր տվյալների բազայի հոսթի անունը պետք է լուծվի այն ցանցում, որին հասնում է կցորդը՝ Cloud DNS փոխկապակցման կամ VPC-ի օգտագործած փոխանցման գոտու միջոցով: Այն ձեր աշխատանքային կայանում լուծելը ոչինչ չի ապացուցում տեղակայված ծառայության մասին, որովհետև ձեր նոթբուքը չի օգտագործում այդ լուծիչը:

Եթե անունը VPC-ի ներսից լուծվում է հանրային հասցեի, դուք պատրաստվում եք վրիպազերծել սխալ firewall-ը:

URL Fetch-ը չի օգտագործում կցորդը

Egress-ի կարգավորումը ծածկում է գործարկման միջավայրի սովորական ելքային սոքեթները, և ժառանգված URL Fetch ծառայությունը այդ ուղու մասը չէ: urlfetch-ի միջոցով թողարկված հարցումը անտեսում է կցորդը, ինչ էլ ասի կոնֆիգուրացիան: Երբ ձախողվող կանչը գտնվում է ավելի հին գրադարանում, որը դեռ օգտագործում է URL Fetch, լուծումը այդ կանչը ստանդարտ HTTP հաճախորդ տեղափոխելն է:

Տվյալների բազայի դրայվերի համար սա հազվադեպ է խնդիր, բայց սա է դասական պատճառը, թե ինչու նույն ծառայությունից մեկ վերջնակետ աշխատում է, իսկ մյուսը՝ ոչ:

Ստուգեք մեկ նեղ հարցումով

Տեղակայեք, ապա տեղակայված տարբերակից կատարեք մեկ թույլատրված տվյալների բազայի գործողություն՝ դիտարկելով հեռավոր կողմը: Տվյալների բազայի կամ VPN դարպասի գրանցած աղբյուրի հասցեն պետք է լինի կցորդինը: Եթե ոչ, հարցումը երբեք չի մտել VPC, և ոչ մի թունելային կոնֆիգուրացիա դա չի ուղղի: Համեմատեք այն կոնսոլում ձեր գտած միջակայքի հետ. անհամապատասխանությունը սովորաբար նշանակում է, որ տարբերակին սպասարկում է երկրորդ կցորդ:

VPC-ի ներսում VM-ից հաջող հարցումը հաստատում է, որ երթուղին գոյություն ունի: Այն չի հաստատում, որ ծառայությունն ընտրել է այն: