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 झोन कार्यान्वित नाही।