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 चाहिए, और फिर वह गंतव्य जो अस्वीकृत ही रहना चाहिए। हर परीक्षण उसी क्लाइंट से चलाएँ जो उत्पादन में यह रास्ता इस्तेमाल करेगा, क्योंकि व्यवस्थापक के वर्कस्टेशन से सफल परीक्षण अलग नेटवर्क वाले डेवलपर लैपटॉप के बारे में बहुत कम साबित करता है।

चुना गया मॉडल, उसके द्वारा कवर किए गए गंतव्य, वे पहचानें जिन्हें वह प्रमाणित करता है और रास्ता उपलब्ध न होने पर विफलता का व्यवहार दर्ज करें। यही रिकॉर्ड अगले अनुरोध को दस्तावेज़ित डिज़ाइन में एक गंतव्य जोड़ने के बजाय सुरंग चुपचाप चौड़ी करने से रोकता है।