Ծրագրավորողին անհրաժեշտ է մեկ SSH նստաշրջան, տվյալների բազայի պորտ կամ լայն մուտք դեպի մեկ տասնյակ մասնավոր ծառայություններ, և այդ հարցումներից յուրաքանչյուրը նույն հարցի տեսք ունի։ Այդպես չէ։ Նպատակակետերը, արձանագրությունները և ներգրավված ինքնությունները որոշում են, թե Google Cloud-ում որ մուտքի ուղին է հարմար, և լռելյայն ամենալայնն ընտրելը ստեղծում է աշխատանք, որը ձեզ պետք չէր ստանձնել։

Գրի առեք նպատակակետերն ու արձանագրությունները

Թվարկեք մասնավոր հասցեները, պորտերը և արձանագրությունները, որոնք աշխատանքին իրականում պետք են, ապա նշեք, թե որ ինքնությունները պետք է առանձին նույնականացվեն։ Տվյալների բազայի պորտը և մասնավոր DNS գոտին տարբեր պահանջներ են, իսկ UDP ծառայությունը լիովին բացառում է ստորև ներկայացված տարբերակներից մեկը։ Գրավոր ցանկը նաև ցույց է տալիս, թե ինչ չեք տրամադրում։ Հենց այդ մասն են հարցնում գրախոսները։

Արեք դա լսող բացելուց առաջ։ Ցանկը հետագայում դառնում է ընդունման թեստ, և դա նեղ թունելը պատահաբար աշխատող լայն թունելից տարբերելու միակ հուսալի միջոցն է։

IAP մի քանի TCP ծառայությունների համար

Identity-Aware Proxy-ի TCP փոխանցումը նույնականացված թունել է տալիս համապատասխան VM ռեսուրսներին՝ առանց ծառայությունը ինտերնետում բացելու։ Առօրյա ձևն է gcloud compute ssh instance-1 --tunnel-through-iap --zone=us-central1-a, և մեկ պորտ կարելի է տեղայնորեն փոխանցել gcloud compute start-iap-tunnel instance-1 5432 --local-host-port=localhost:15432 --zone=us-central1-a-ով։

Երեք բան պետք է համընկնի. զանգահարողին անհրաժեշտ է IAP թունելի մուտքի դերը, հրդեհային պատը պետք է թույլատրի IAP աղբյուրի միջակայքը, և նպատակակետը պետք է հասանելի լինի օրինակի վրա։ Թունել ստեղծելու թույլտվությունը տվյալների բազայի հավատարմագիր, SSH մուտք կամ RDP նստաշրջան չէ, ուստի հավելվածի նույնականացումը թողեք իր տեղում։

IAP-ի TCP փոխանցումը երրորդ շերտի VPN չէ։ Այն TCP-ն տեղափոխում է ընտրված նպատակակետ, ոչ կամայական IP երթևեկություն կամ UDP, և վատ է համապատասխանում, երբ հավելվածին անհրաժեշտ է մասնավոր DNS շատ ծառայությունների միջև։

Հեռավոր մուտքի VPN ավելի լայն հասանելիության համար

Երբ պահանջվում են մի քանի նպատակակետեր, արձանագրություններ կամ մասնավոր DNS գոտիներ, ավելի լավ ձև է VM-ի կամ աջակցվող սարքի վրա բացահայտ կառավարվող հեռավոր մուտքի VPN-ը։ Այդ տեղակայումը առանձին է Google-ի կողմից կառավարվող Cloud VPN-ից. դուք եք տիրապետում հաճախորդի ինքնության գրանցմանը, ծրագրային թարմացումներին, հաճախորդի երթուղիներին և VPC-ի վերադարձի երթուղիներին։

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

Cloud VPN-ը կայքի դարպաս է, ոչ նոթբուքային պրոֆիլ

Google Cloud VPN-ը IPsec-ի միջոցով միացնում է զուգընկեր դարպասները, և նրա հաճախ տրվող հարցերը բաժանում են այդ կայք-կայք դերը հաճախորդ-դարպաս մուտքից։ Թունել ստեղծելը չի առաջացնում պրոֆիլ, որը աշխատողը ներմուծում է նոթբուքում։ Տարբերությունը կարևոր է, երբ ինչ-որ մեկը խնդրում է Cloud VPN պրոֆիլ։ Պատասխանը այլ ապրանք է։

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

Ստուգեք և գրանցեք

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

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

Առնչվող հոդվածներ