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 جڑتا ہے مگر اندرونی نام حل نہیں کر سکتا، وہ ڈویلپر کے ورک فلو کو اتنا ہی مکمل ناکام کرتا ہے جتنا کبھی نہ جڑنے والا VPN کرتا ہے۔

Cloud VPN ایک سائٹ گیٹ وے ہے، لیپ ٹاپ پروفائل نہیں

Google Cloud VPN IPsec کے ذریعے ہم منصب گیٹ ویز کو جوڑتا ہے، اور اس کے اکثر پوچھے جانے والے سوالات اس سائٹ سے سائٹ کردار کو کلائنٹ سے گیٹ وے رسائی سے الگ کرتے ہیں۔ سرنگ بنانے سے ایسا پروفائل نہیں بنتا جو ملازم لیپ ٹاپ پر درآمد کرے۔ یہ فرق اس وقت اہم ہوتا ہے جب کوئی Cloud VPN پروفائل مانگے۔ جواب کوئی اور مصنوع ہے۔

گیٹ وے جو اچھی طرح کرتا ہے وہ ہے دفتر کے نیٹ ورک کے پیچھے موجود مشینوں کو VPC میں راستہ دینا۔ یہ ہر ملازم کی تصدیق نہیں کرتا اور ایپلیکیشن اجازتیں نہیں دیتا، اس لیے وہ پالیسیاں نیٹ ورک اور ایپلیکیشن پرتوں پر رہتی ہیں جہاں شناخت کے مطابق نافذ کی جا سکتی ہیں۔

تصدیق کریں اور ریکارڈ کریں

پہلے سب سے تنگ منزل، پھر وہ جسے DNS درکار ہے، اور پھر وہ منزل جو مسترد ہی رہنی چاہیے آزمائیں۔ ہر امتحان اسی کلائنٹ سے چلائیں جو پیداوار میں یہ راستہ استعمال کرے گا، کیونکہ منتظم کے ورک اسٹیشن سے کامیاب امتحان مختلف نیٹ ورک والے ڈویلپر لیپ ٹاپ کے بارے میں بہت کم ثابت کرتا ہے۔

منتخب ماڈل، اس کی محیط منزلیں، تصدیق شدہ شناختیں اور راستہ دستیاب نہ ہونے پر ناکامی کا رویہ ریکارڈ کریں۔ یہی ریکارڈ اگلی درخواست کو دستاویزی ڈیزائن میں ایک منزل شامل کرنے کے بجائے سرنگ خاموشی سے وسیع کرنے سے روکتا ہے۔