Google API-ն VPN-ով։ երթուղի՛ր VIP-ը, ոչ միայն ենթացանցը
VPC-ի ենթացանցի երթուղին չի ընտրում API-ի VIP հասցեները։ Լուծիր ճիշտ անունները, հայտարարիր VIP նախածանցը, պահպանիր VPC-ի վերադարձի ուղին և հետո փորձարկիր HTTPS-ը։
Մուտք գործիր SSH-ով տեղական սերվեր, բարձրացրու թունելը, և մասնավոր VM-ը պատասխանում է, այնուհետև Google API-ին առաջին կանչը ձախողվում է առանց երթուղու։ VM-ի ենթացանցը և API-ի VIP հասցեները տարբեր նպատակակետեր են, ուստի մեկի երթուղին չի ընտրում մյուսին։ Երեք պայման պետք է պահպանվի, որպեսզի մասնավոր API կանչը աշխատի։ API-ի անունը պետք է լուծվի VIP-ի, VIP նախածանցը պետք է հայտարարվի թունելով, և VPC-ն պետք է իմանա, թե ինչպես պատասխանը հետ ուղարկել։ Ping-ը այդ մասին ոչինչ չի ասում, և ենթացանցի մեքենային աշխատող SSH սեսիան նույնպես։
API-ի VIP հասցեները առանձին նպատակակետեր են
Google-ը հրապարակում է առանձնացված VIP հասցեներ տեղական ցանցից API մուտքի համար, և հենց այդ հասցեներն է, որ քո DNS-ը պետք է վերադարձնի API անունների համար։ Երկուսն էլ փոքր նախածանցներ են, և ոչ մեկը RFC 1918 տարածություն չէ:
| Record | Resolves to | What it does not give you |
|---|---|---|
| private.googleapis.com | 199.36.153.8/30, the general front door for Google APIs | not a bypass around a service perimeter |
| restricted.googleapis.com | 199.36.153.4/30, reachable only for services a perimeter allows | not the whole API surface, so some names stay out of reach |
Հանրային տեսք ունեցող հասցեները չեն նշանակում, որ երթուղին պետք է լքի թունելը սովորական ինտերնետի համար։ Նախածանցները գոյություն ունեն, որպեսզի տեղական հաճախորդը հասնի Google-ի ճակատային մասերին աջակցվող ուղով, այլ ոչ թե կամայական ելքի կետով։ Վերաբերվիր նրանց որպես թունելին պատկանող նպատակակետերի, ոչ որպես հետազոտվող հոսթերի։ Ինտերնետ ելքի համար գրված firewall կանոնը սովորաբար դեն է նետում նրանց, և սա հաճախակի պատճառ է, թե ինչու կանչը ձախողվում է նախքան սկսելը։
DNS-ն է որոշում, թե որ վերջնակետին ես հասնում
Ուղղիր տեղական լուծիչը այն գրառումներին, որոնք Google-ը փաստագրում է ընտրված վերջնակետի համար, որպեսզի հավելվածին անհրաժեշտ անունները պատասխանեն այդ VIP-ով։ Միայն googleapis.com քարտեզագրելը գույքագրում չէ: փաթեթների ռեեստրները, կոնտեյներների ռեեստրները և միգրացիայի միակցիչները ունեն իրենց փաստագրված անունները։ Սահմանափակ VIP-ը նույնպես չի կրում ամեն ծառայություն, ուստի լուծված անունը կարող է դեռ չաջակցվել։ Գրիր այն դոմենները, որոնց հավելվածն իրականում դիմում է, նախքան լուծիչին դիպչելը։
VPC-ում VM հասցե գուշակելը որպես ծառայության անվան փոխարինում ուղղում չէ, և այն սովորաբար թաքցնում է DNS-ի բացը, մինչև մեկ այլ հաճախորդ ձախողվի։
Հայտարարիր VIP նախածանցը, պահպանիր մնացածը
BGP-ի վրա հիմնված կապի դեպքում Cloud Router-ը պետք է հայտարարի ընտրված VIP նախածանցը, որպեսզի տեղական երթուղիչը սովորի այդ տիրույթը նախատեսված սեսիայով։ Միայն VPC ենթացանցերի հայտարարումը չի ավելացնում այդ տիրույթը, և տեղական երթուղիչը շարունակում է օգտագործել իր լռելյայն ուղին այդ հասցեների համար։ Երթուղային աղյուսակի նախածանցը միակ ապացույցն է, որ հայտարարումը հատել է սեսիան։
Պահպանիր գոյություն ունեցող հայտարարումները, մինչ ավելացնում ես նորը, որովհետև երթուղիչի մակարդակի և գործընկերոջ մակարդակի ընտրանքներն ունեն տարբեր հասանելիություն, և հավաքածուն փոխելը կարող է հետ քաշել ցանցեր, որոնք արդեն աշխատում էին։ Ապա ստուգիր արդյունավետ հայտարարումը յուրաքանչյուր սեսիայում, այլ ոչ թե ամբողջ երթուղիչում։ Բացակայող նախածանցը և հետ քաշված նախածանցը տեղական կողմից նույն տեսքն ունեն, ուստի հենց սեսիայի տեսքն է, որ բացթողումը տարբերում է ռեգրեսիայից։
VPC կողմին պետք է իր երթուղին և վերադարձի ուղին
VPC-ի ներսում VIP-ի ուղին պետք է օգտագործի լռելյայն ինտերնետ դարպասը որպես հաջորդ ցատկ, և չնայած անվանը այդ տրաֆիկը մնում է Google-ի ցանցում։ VPC-ին նաև պետք է վերադարձի երթուղի դեպի տեղական աղբյուր VPN-ով, ինչը առանձին օբյեկտ է հայտարարված նախածանցից։ Հաշվի առ փաստագրված տարածաշրջանային երթուղավորման պահանջները, երբ թունելը և հաճախորդը նույն տարածաշրջանում չեն։
Ստուգիր վերադարձի ուղին ինքնուրույն, որովհետև աշխատող հարցումի ուղղությունը կարող է թաքցնել կոտրված պատասխանի ուղղությունը։ Երկու ուղղություն, երկու երթուղի, և յուրաքանչյուրը ձախողվում է իր ախտանիշով։
Փորձարկիր հարցումը, ապա կարդա մերժումը
ICMP արձագանքը այս VIP-ներից պատասխան չի ստանում, ուստի ձախողված ping-ը ոչինչ չի ապացուցում, իսկ հաջողվածը՝ շատ քիչ։ Իրական հաճախորդից ուսումնասիրիր անվան պատասխանը և ընտրված երթուղին, ապա կատարիր լիազորված HTTPS հարցում այն ծառայությանը, որ քեզ հետաքրքրում է։ Եթե հարցումը հասնում է ծառայությանը և մերժվում, նայիր հավատարմագրերին, IAM-ին և ցանկացած գործող ծառայության պարագծի քաղաքականությանը։
Մասնավոր երթուղավորումը API լիազորում չի տալիս և չի փոխում, թե ինչ կարող է անել ինքնությունը։ Փոխադրման հաջողությունը և լիազորված պատասխանը առանձին արդյունքներ են, և քեզ պետք են երկուսն էլ։ Պահիր նաև IPv6 ուղին բացահայտ, որովհետև IPv4 նախածանցերի կարգավորումը ոչինչ չի ասում IPv6-ը նախընտրող հաճախորդի մասին։
Google-ի ուղեցույցը՝ Private Google Access տեղական ցանցից միասին ընդգրկում է DNS գրառումները և երթուղավորման պահանջները, ուստի համեմատիր լուծիչի և հայտարարման կարգավորումները դրա հետ, այլ ոչ թե ֆորումի գրառման։ Ապա նորից գործարկիր նույն հարցումը և գրանցիր պատասխանն ու երթուղին նույն տոմսում։