VPN-ը դեպի VPC աշխատում է, բայց կառավարվող ծառայության ժամանակը սպառվում է
Թունելը ավարտվում է ձեր եզրին, ոչ թե մատակարարի առջևի դռանը։ Նախքան երթուղին փոխելը դասակարգեք թիրախը որպես VM-ում հոսթավորված, VPC-ին կցված կամ միայն հանրային։
Կառավարվող տվյալների բազային VPN-ով հասնելը սովորաբար ձախողվում է մի պատճառով, որը ոչ ոք չի գրել ուղեցույցում՝ թունելը ավարտվում է ձեր ցանցի եզրին, մինչդեռ ծառայությունը երբեք չի եղել դրա ձեր կողմում։ Երթուղիների աղյուսակը ճիշտ է թվում, թունելը հայտնում է, որ ակտիվ է, և կապը միևնույն է ժամանակը սպառում է։ Կատարեք ստորև նշված չորս ստուգումները հերթականությամբ և կանգ առեք առաջինի վրա, որի հաջողության պայմանը չի բավարարվում, քանի որ դրանից հետո յուրաքանչյուր ստուգում ենթադրում է, որ նախորդներն անցել են։
Ստուգում առաջին. որտեղ է իրականում ապրում վերջնակետը։
VPN դարպասը միացնում է երկու ցանցեր, որոնց հասցեավորումը վերահսկում եք դուք։ Կառավարվող ծառայությունը գործում է մատակարարի սեփական առջևի դռան հետևում, և այդ դուռը ընդունում է երեք ձևերից մեկը՝ կախված ապրանքից։ Եթե չգիտեք, թե որ ձևի հետ գործ ունեք, ոչ մի երթուղային աշխատանք չի օգնի, որովհետև խափանումը գուցե ընդհանրապես երթուղային խափանում չէ։
| Shape | What it means | Pass condition |
|---|---|---|
| Software on your VM | Ordinary subnet addressing | Route and security group permit the client |
| Attached to your VPC | Private, but only inside that VPC | Endpoint associated, source allowed, route present |
| Provider-hosted, public endpoint | Optional private link, not private by default | A private endpoint exists and DNS points at it |
Կորսված կեսօրների մեծ մասը գալիս է այս դասակարգումը բաց թողնելուց և անմիջապես երթուղիների աղյուսակին անցնելուց։ Մատակարարի մոտ հոսթավորված հանրային վերջնակետով ծառայությունը ձեր թունելի հետևում չէ, ինչ էլ որ ասի գծապատկերը, իսկ VPC-ին կցվածը երբեք չի հայտնվի հանրային DNS պատասխանում։
Ստուգում երկրորդ. VPC-ին կցված ծառայություն, օրինակ ElastiCache
Այդ տեսակի քեշերը հասցեավորվում են ձեր սեփական VPC-ի ներսում և ընդհանրապես ինտերնետին ուղղված լսող չունեն։ Նույն VPC-ում ավարտվող հաճախորդային VPN-ը կարող է հասնել նրանց, բայց միայն այն դեպքում, երբ երեք պայման միաժամանակ համընկնեն։ Քեշի վերջնակետը պետք է կապված լինի ենթացանցերի հետ, որոնք ձեր թունելը տեսնում է, նրա անվտանգության խումբը պետք է թույլ տա այն հասցեն, որտեղից գալիս են ձեր հաճախորդները, և հաճախորդի կողմին անհրաժեշտ է երթուղի, որը ծածկում է քեշի ենթացանցերը։
Տարածված սխալը ենթադրելն է, որ մոտակայքում ինչ-որ միացում հաշվի է առնվում։ VPN-ը այլ VPC-ին կցելը կամ միայն peering-ի վրա հենվելը չի տարածում քեշի անվտանգության խումբը կամ նրա ենթացանցի երթուղիների աղյուսակը ձեր հաճախորդների վրա։ Երբ գործող թունելը ավարտվում է այլ տեղ, սովորական պահուստային լուծումը ցատկող հոսթն է կամ այդ VPC-ի ներսում տեղադրված VPN սերվերը։ Այդ պահուստային լուծումը շրջանցում է, ոչ թե նախագիծ, և ուղեցույցում այն պետք է հենց այդպես նշվի։
Ստուգում երրորդ. հանրային անունով PaaS վերջնակետ
Azure Database for PostgreSQL-ը ներկայացնում է հանրային սերվերի անուն։ Այն ձեզ չի տալիս մասնավոր հասցե, որը կարող եք ամրացնել hosts ֆայլում և երթուղավորել դարպասով։ Վիրտուալ ցանցի ծառայության վերջնակետերը սահմանափակում են, թե որ ենթացանցերը կարող են հասնել ռեսուրսին՝ դրանք չեն լիազորում VPN-ով եկող տեղական հաճախորդին։
Մասնավոր հասանելիություն ստանալը նշանակում է ներմուծել մասնավոր վերջնակետ կամ մասնավոր կապի նախագիծ, ապա ավելացնել մասնավոր DNS գոտի, որպեսզի հանրային անունը պատասխանի այդ վերջնակետով՝ ինտերնետի փոխարեն։ VPN-ը ծառայության վերջնակետի կանոնի հետ համատեղ այլ ճարտարապետություն է, որը նման է երևում միայն գծապատկերում։ App Service-ը հետևում է նույն տրամաբանությանը հակառակ ուղղությամբ. VNet ինտեգրումը թույլ է տալիս հավելվածին ելքային զանգեր կատարել VNet-ի մեջ, և այն չի ստեղծում ձեր թունելից ներս եկող մասնավոր ուղի։ Ուստի ներս եկող մասնավոր հասանելիությունը պահանջում է մասնավոր վերջնակետ, App Service Environment կամ հավելվածի առջևում դրված դարպաս, և թե դրանցից որն եք կարող օգտագործել, կախված է պլանից։
Ստուգում չորրորդ. սեփական առջևի դուռ ունեցող ապրանքներ
Firebase Hosting-ը հնարավոր չէ կցել Cloud VPN-ին, որովհետև հոսթինգի շերտը գլոբալ առջևի մասն է, այլ ոչ թե ինչ-որ բան ծրագրի VPC-ի ներսում։ Փաստաթղթավորված այլընտրանքը վերահսկվող մուտքի կետը ինքներդ կառուցելն է՝ պրոքսի ինստանսով կամ դույլով հենված բեռնվածության հավասարեցուցիչով։ Ամեն դեպքում կայքը դադարում է մաքուր հոսթինգ ապրանք լինելուց և դառնում է ենթակառուցվածք, որը հիմա դուք եք շահագործում։ Արժե այդ փոխանակումը անվանել նախքան ինչ-որ մեկը կխոստանա, որ թունելը կծածկի այն։
Private API Gateway-ը ավելի մոտ է VPC ծառայությունների կողմին. interface տիպի VPC վերջնակետը հրապարակում է հոսթի անուն, որի պատասխանները մասնավոր հասցեներ են, և ձեր տարածքից երթևեկությունը գալիս է թունելով կամ հատուկ փոխկապով։ Վերջնակետը պետք է կապված լինի API-ին, իսկ վկայականը և հոսթի անունը պետք է համապատասխանեն զանգահարողների օգտագործած հատուկ տիրույթին։
Google Cloud VPN թունելները կապվում են գործընկեր IP հասցեներին, ոչ անուններին։ DNS փոխանցումը կազմաձևվում է առանձին, ինչի պատճառով թունելը կարող է լիովին առողջ լինել, մինչ հեռավոր մասնավոր գոտում որոնումները դեռ ձախողվում են։
Ապա գտեք սահմանը
Գործարկեք նույն կապը VPC-ի ներսում գտնվող VM-ից։ Երբ այնտեղ հաջողվի, իսկ VPN հաճախորդից ձախողվի, բացը գտնվում է հաճախորդի ուղու և ծառայության վերջնակետի միջև՝ երթուղի, անվտանգության խումբ, վերջնակետի քաղաքականություն կամ անուն։ Երբ երկու փորձերն էլ ձախողվեն, այդ ցանցում ոչինչ չի կարող հասնել ծառայությանը, և VPN-ը երբեք խոչընդոտ չի եղել։
getent hosts db.internal.example
nc -vz db.internal.example 5432Անվան որոնումը և պորտի ստուգումը կատարեք առանձին, որովհետև դրանք ձախողվում են տարբեր պատճառներով, և զույգը ձեզ ասում է, թե ուղու որ կեսն է կոտրված։ Հանրային հասցեի վերածվող անունը ձեզ ասում է, որ մասնավոր DNS գոտին գործի մեջ չէ։