د Google Cloud VPC ته د پراختیاکوونکي لرې لاسرسی: سمه لار وټاکئ

یو پراختیاکوونکي ته یوه SSH غونډه، د ډیټابیس پورټ یا لسګونو شخصي خدمتونو ته پراخه لاسرسی ته اړتیا وي، او له دې غوښتنو هر یو د ورته پوښتنې په څېر ښکاري۔ داسې نه ده۔ هدفونه، پروتوکولونه او ښکېل هویتونه هغه څه دي چې ټاکي په Google Cloud کې کومه لاسرسي لار ښه ده، او په ډیفالټ ډول تر ټولو پراخه غوره کول هغه کار جوړوي چې تاسو ته د ساتلو اړتیا نه وه۔

هدفونه او پروتوکولونه ولیکئ

هغه شخصي پتې، پورټونه او پروتوکولونه ولیکئ چې کار واقعاً ورته اړتیا لري، بیا په نښه کړئ چې کوم هویتونه باید جلا تصدیق شي۔ د ډیټابیس پورټ او شخصي DNS زون بېلابېلې غوښتنې دي، او UDP خدمت لاندې انتخابونو څخه یو په بشپړ ډول حذفوي۔ لیکلې لیست دا هم ښيي چې تاسو څه نه ورکوئ۔ بیاکتونکي هماغه برخه پوښتنه کوي۔

دا د اورېدونکي له پرانیستلو دمخه وکړئ۔ لیست وروسته د منلو ازموینه ګرځي، او تنګ تونل له هغه پراخه تونل څخه چې ناڅاپه کار کوي د توپیر یوازینۍ باوري لاره همدا ده۔

د څو TCP خدمتونو لپاره IAP

په 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 ته اړتیا لري، او بیا هغه هدف چې باید رد پاتې شي ازموئ۔ هره ازموینه له هماغه پیرودونکي څخه چلئ چې په تولید کې به دا لار کاروي، ځکه له مدیر د کار سټیشن څخه بریالۍ ازموینه د بلې شبکې لرونکي پراختیاکوونکي لپ ټاپ په اړه ډېر لږ ثابتوي۔

ټاکل شوی ماډل، هغه هدفونه چې پوښي یې، هغه هویتونه چې تصدیقوي یې او د ناکامۍ چلند کله چې لار نه وي موجوده ثبت کړئ۔ همدا ثبت هغه څه دي چې بلې غوښتنې ته اجازه نه ورکوي چې په خپله خوښه تونل پراخ کړي پرځای دې چې یو هدف مستند ډیزاین ته ورزیات کړي۔