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 आवश्यक असलेले, आणि नंतर नाकारलेलेच राहिले पाहिजे असे गंतव्य तपासा। प्रत्येक चाचणी उत्पादनात हा मार्ग वापरणाऱ्या त्याच क्लायंटवरून चालवा, कारण प्रशासकाच्या वर्कस्टेशनवरून यशस्वी चाचणी वेगळ्या नेटवर्कच्या डेव्हलपर लॅपटॉपबद्दल फारसे सिद्ध करत नाही।

निवडलेले मॉडेल, ते व्यापणारी गंतव्ये, प्रमाणित करणारी ओळखी आणि मार्ग उपलब्ध नसताना अपयशाचे वर्तन नोंद करा। हीच नोंद पुढील विनंतीला दस्तऐवजीकृत रचनेत एक गंतव्य जोडण्याऐवजी बोगदा गुपचूप रुंद करण्यापासून थांबवते।