VPC मा VPN काम गर्छ, तर व्यवस्थापित सेवाको समय सकिन्छ
सुरुङ तपाईंको किनारामा सकिन्छ, प्रदायकको अगाडिको ढोकामा होइन। मार्ग परिवर्तन गर्नु अघि लक्ष्यलाई VM मा होस्ट गरिएको, VPC सँग जोडिएको वा केवल सार्वजनिक भनी वर्गीकृत गर्नुहोस्।
VPN मार्फत व्यवस्थापित डेटाबेसमा पुग्ने काम सामान्यतया कसैले रनबुकमा नलेखेको कारणले असफल हुन्छ: सुरुङ तपाईंको नेटवर्कको किनारामा सकिन्छ, जबकि सेवा कहिल्यै त्यसको तपाईंको पट्टि थिएन। मार्ग तालिका सही देखिन्छ, सुरुङ सक्रिय रहेको जनाउँछ, र जडानले त्यसै पनि समय सक्छ। तलका चार जाँच क्रममा गर्नुहोस् र सफलताको सर्त पूरा नहुने पहिलो जाँचमा रोकिनुहोस्, किनकि त्यसपछिका हरेक जाँचले अघिल्ला पूरा भएको मान्छ।
जाँच एक: अन्तिम बिन्दु वास्तवमा कहाँ बस्छ?
VPN गेटवेले तपाईंले नियन्त्रण गर्ने ठेगाना भएका दुई नेटवर्क जोड्छ। व्यवस्थापित सेवा प्रदायकको आफ्नै अगाडिको ढोकाभित्र चल्छ, र त्यो ढोका उत्पादनअनुसार तीनमध्ये एक आकार लिन्छ। कुन आकारसँग व्यवहार गर्दै हुनुहुन्छ भन्ने थाहा छैन भने कुनै पनि मार्ग कार्यले सहयोग गर्दैन, किनकि खराबी मार्गको खराबी नै नहुन सक्छ।
| Shape | What it means | Pass condition |
|---|---|---|
| Software on your VM | Ordinary subnet addressing | Route and security group permit the client |
| Attached to your VPC | Private, but only inside that VPC | Endpoint associated, source allowed, route present |
| Provider-hosted, public endpoint | Optional private link, not private by default | A private endpoint exists and DNS points at it |
अधिकांश बर्बाद भएका दिउँसोहरू यो वर्गीकरण छोडेर सिधै मार्ग तालिकामा जाँदा हुन्छन्। सार्वजनिक अन्तिम बिन्दु भएको प्रदायक-होस्ट गरिएको सेवा, रेखाचित्रले जे भने पनि तपाईंको सुरुङपछाडि हुँदैन, र VPC सँग जोडिएको सेवा सार्वजनिक DNS उत्तरमा कहिल्यै देखिँदैन।
जाँच दुई: ElastiCache जस्तो VPC सँग जोडिएको सेवा
त्यस्ता क्यासहरू तपाईंको आफ्नै VPC भित्र ठेगाना पाउँछन् र इन्टरनेटतर्फ फर्किएको श्रोता तिनीहरूसँग हुँदैन। त्यही VPC मा सकिने क्लाइन्ट VPN तिनीहरूसम्म पुग्न सक्छ, तर तीन सर्त एकैचोटि मिलेपछि मात्र। क्यासको अन्तिम बिन्दु तपाईंको सुरुङले देख्न सक्ने सबनेटसँग जोडिएको हुनुपर्छ, त्यसको सुरक्षा समूहले तपाईंका क्लाइन्ट आउने ठेगानालाई अनुमति दिनुपर्छ, र क्लाइन्ट पक्षमा क्यास सबनेट ढाक्ने मार्ग चाहिन्छ।
सामान्य गल्ती भनेको नजिकैको जडान पनि गनिन्छ भनी ठान्नु हो। VPN लाई अर्को VPC सँग जोड्ने, वा केवल peering मा भर पर्ने कामले क्यासको सुरक्षा समूह वा त्यसको सबनेटको मार्ग तालिका तपाईंका क्लाइन्टसम्म विस्तार गर्दैन। विद्यमान सुरुङ अन्तै सकिएमा त्यो VPC भित्र राखिएको जम्प होस्ट वा VPN सर्भर सामान्य विकल्प हुन्छ। त्यस्तो विकल्प डिजाइन नभई छल्ने उपाय हो, र रनबुकमा त्यसै गरी चिन्ह लगाउनुपर्छ।
जाँच तीन: सार्वजनिक नाम भएको PaaS अन्तिम बिन्दु
Azure Database for PostgreSQL ले सार्वजनिक सर्भर नाम प्रस्तुत गर्छ। यसले तपाईंलाई hosts फाइलमा पिन गरेर गेटवेबाट मार्ग पुर्याउन सकिने निजी ठेगाना दिँदैन। भर्चुअल नेटवर्क सेवा अन्तिम बिन्दुहरूले कुन सबनेटले स्रोतसम्म पुग्न सक्छन् भन्ने सीमित गर्छन्; तिनीहरूले VPN मार्फत आउने स्थानीय क्लाइन्टलाई अधिकार दिँदैनन्।
निजी पहुँच पाउनु भनेको निजी अन्तिम बिन्दु वा निजी लिङ्क डिजाइन भित्र्याएर त्यसपछि निजी DNS क्षेत्र थप्नु हो, ताकि सार्वजनिक नामले इन्टरनेटको सट्टा त्यही अन्तिम बिन्दुसँग जवाफ दियोस्। सेवा अन्तिम बिन्दु नियमसँग जोडिएको VPN अर्कै वास्तुकला हो जुन रेखाचित्रमा मात्र उस्तै देखिन्छ। App Service ले त्यही तर्क विपरीत दिशाबाट पछ्याउँछ: VNet एकीकरणले एपलाई VNet भित्र बाहिर जाने कल गर्न दिन्छ, र यसले तपाईंको सुरुङबाट भित्र आउने निजी बाटो बनाउँदैन। त्यसैले भित्र आउने निजी पहुँचका लागि निजी अन्तिम बिन्दु, App Service वातावरण वा एपअगाडि राखिएको गेटवे चाहिन्छ, र तीमध्ये कुन प्रयोग गर्न सकिन्छ योजनामा निर्भर हुन्छ।
जाँच चार: आफ्नै अगाडिको ढोका भएका उत्पादनहरू
Firebase Hosting लाई Cloud VPN सँग जोड्न सकिँदैन, किनकि होस्टिङ तह विश्वव्यापी अगाडिको भाग हो, परियोजनाको VPC भित्रको कुरा होइन। अभिलेखित विकल्प भनेको नियन्त्रित प्रवेश बिन्दु आफैं बनाउनु हो, प्रोक्सी इन्स्ट्यान्स वा बाल्टिनमा आधारित लोड ब्यालेन्सरसँग। जसरी भए पनि साइट शुद्ध होस्टिङ उत्पादन रहन छोड्छ र अब तपाईंले चलाउने पूर्वाधार बन्छ। सुरुङले त्यसलाई ढाक्नेछ भनी कसैले वाचा गर्नु अघि यो साटासाटलाई नाम दिन लायक छ।
Private API Gateway VPC सेवाको पट्टि नजिक छ: interface प्रकारको VPC अन्तिम बिन्दुले जवाफहरू निजी ठेगाना हुने होस्टनाम प्रकाशित गर्छ, र तपाईंको परिसरबाट ट्राफिक सुरुङ वा समर्पित अन्तरजडानबाट आउँछ। अन्तिम बिन्दु API सँग जोडिएको हुनुपर्छ, र प्रमाणपत्र तथा होस्टनाम कल गर्नेहरूले प्रयोग गर्ने अनुकूलित डोमेनसँग मिल्नुपर्छ।
Google Cloud VPN सुरुङहरू नामसँग होइन, सहकर्मी IP ठेगानासँग बाँधिन्छन्। DNS अग्रगमन छुट्टै कन्फिगर गरिन्छ, त्यसैले सुरुङ पूर्ण रूपमा स्वस्थ हुँदा पनि टाढाको निजी क्षेत्रमा खोजी असफल हुन सक्छ।
त्यसपछि सीमा पत्ता लगाउनुहोस्
VPC भित्रको VM बाट त्यही जडान चलाउनुहोस्। त्यहाँ सफल भई VPN क्लाइन्टबाट असफल भएमा, अन्तर क्लाइन्टको मार्ग र सेवाको अन्तिम बिन्दुबीच हुन्छ: मार्ग, सुरक्षा समूह, अन्तिम बिन्दु नीति वा नाम। दुवै प्रयास असफल भएमा त्यो नेटवर्कमा केही पनि सेवासम्म पुग्न सक्दैन, र VPN कहिल्यै बाधा थिएन।
getent hosts db.internal.example
nc -vz db.internal.example 5432नामको खोजी र पोर्ट जाँच छुट्टाछुट्टै गर्नुहोस्, किनकि ती फरक कारणले असफल हुन्छन् र त्यो जोडीले मार्गको कुन आधा भाग बिग्रिएको छ भनी बताउँछ। सार्वजनिक ठेगानामा हल हुने नामले तपाईंलाई निजी DNS क्षेत्र सक्रिय छैन भनी बताउँछ।