स्थानीय डेटाबेस क्लाइन्ट र निजी RDS: जडानको समय किन सकिन्छ

एक विकासकर्ताको ल्यापटप निजी RDS अन्त्यबिन्दुमा जोडिँदा समय सकिन्छ, जबकि तीही प्रमाणहरू बास्टियन होस्टबाट काम गर्छन्। केही पनि खसेको छैन। त्यो ल्यापटप र डेटाबेसबीचको बाटोमा तीनमध्ये एक कुरा छुटेको छ: समाधान हुने नाम, ट्राफिक बोक्ने मार्ग, वा डेटाबेसले वास्तवमा देख्ने स्रोतलाई अनुमति दिने सुरक्षा समूहको नियम। अरू दुई बदल्नुअघि कुन छुटेको छ पत्ता लगाउनुहोस्।

असफलता सही तहमा पढ्नुहोस्

समय सकिनु एउटा त्रुटि होइन। समाधान नहुने नाम प्याकेट मेसिन छोड्नुअघि नै असफल हुन्छ। मार्ग नभएको ठेगानाले प्याकेट कालो प्वालमा पठाउँछ। फिल्टर गरिएको पोर्टले गलत होस्टजस्तै देखिने प्रतीक्षा बनाउँछ। चरणहरू क्रममा चलाउनुहोस् र पहिलो असफल हुने चरणमा रोकिनुहोस्।

dig +short db.internal.example
nc -vz db.internal.example 5432

यदि नामले सार्वजनिक ठेगाना फर्काउँछ, वा केही पनि फर्काउँदैन, टनेल अझै समस्या होइन।

यदि नाम समाधान भयो र पोर्ट परीक्षण अड्कियो, तपाईंले समाधान गरेको ठेगानालाई डेटाबेसले रिपोर्ट गर्ने ठेगानासँग तुलना गर्नुहोस्। व्यवस्थित अन्त्यबिन्दु VPC भित्र निजी ठेगानामा र बाहिर कुनै उपयोगी कुरामा समाधान हुन सक्छ, र पुरानो खोजीबाट प्रतिलिपि गरिएको ठेगानाले अब जवाफ नदिने होस्टतर्फ देखाउनेछ।

टनेललाई मार्गबाट अलग गर्नुहोस्

क्लाइन्ट VPN जोड्नु भनेको हरेक निजी दायरा स्वतः मार्गनिर्देशन हुनु होइन। प्रोफाइलले सेवाले धकेल्ने मार्गहरू बोक्छ, र क्लाइन्टले तीमध्ये केही मात्र स्थापना गर्न सक्छ। क्लाइन्टले वास्तवमा कुन दायरा थप्यो र डेटाबेसको ठेगाना तीमध्ये एउटाभित्र पर्छ कि पर्दैन हेर्नुहोस्।

ip route get 10.20.40.15
ip addr show tun0

टनेल इन्टरफेसतर्फ देखाउने मार्ग आवश्यक छ; त्यो पर्याप्त छैन, किनकि अर्को पक्षले अझै ट्राफिक स्वीकार गर्नुपर्छ।

स्प्लिट-टनेल प्रोफाइलहरू यो आधा असफलताको सामान्य स्रोत हुन्। ती प्रोफाइल जुन अनुप्रयोगका लागि बनाइएको थियो त्यसका लागि काम गर्छन् र डेटाबेसको दायरा टनेलबाहिर छोड्छन्, जसले फायरवालले बनाउने ठ्याक्कै त्यही समय सकिने अवस्था बनाउँछ।

सुरक्षा समूहलाई वास्तविक स्रोतसँग मिलाउनुहोस्

RDS सुरक्षा समूहले मानिसलाई होइन, स्रोतलाई अनुमति दिन्छ। वास्तुकलाअनुसार स्रोत VPN क्लाइन्ट पूल, बास्टियनको निजी ठेगाना, वा ट्राफिक अनुवाद हुने NAT ठेगाना हुन सक्छ। नियम र प्याकेटको वास्तविक स्रोत सँगै पढ्नुहोस्।

aws ec2 describe-security-groups --group-ids sg-0123456789abcdef0 \
  --query 'SecurityGroups[].IpPermissions'

एउटा ल्यापटपको घरको ठेगानाका लागि नियम पहुँच डिजाइन होइन, मर्मतको समस्या हो।

बाटोमा क्लाइन्ट VPN वा NAT गेटवे हुँदा, डेटाबेसले विकासकर्ताको टनेल ठेगानाको सट्टा अनुवादकको ठेगाना देख्न सक्छ। त्यसैले काम गर्ने बास्टियन सेटअपबाट प्रतिलिपि गरिएको नियम ल्यापटपका लागि असफल हुन सक्छ: दुवै बाटो फरक स्रोतबाट आउँछन्, तर दुवै आन्तरिक देखिन्छन्।

फराकिलो बाटोभन्दा साँघुरो बाटो रोज्नुहोस्

एक विकासकर्तालाई एउटा डेटाबेस चाहिँदा, सत्रमा आधारित फर्वार्डिङ पूर्ण नेटवर्क टनेलभन्दा चलाउन सस्तो पर्छ। स्थानीय क्लाइन्ट फर्वार्ड गरिएको पोर्टमा जोडिन्छ, र टाढाको घटकले नेटवर्कभित्रबाट डेटाबेस जडान बनाउँछ।

ssh -N -L 5432:db.internal.example:5432 bastion.internal.example

त्यो डिजाइनमा TLS प्रमाणीकरण अटुट राख्नुहोस्। क्लाइन्टले अपेक्षा गरेको नामसँग सर्भर प्रमाणपत्र अझै प्रमाणित गर्नुपर्छ; स्थानीय फर्वार्ड गरिएको पोर्ट प्रमाणीकरण बन्द गर्ने कारण होइन, र बन्द गर्नुले पक्रन लायकको त्यही पहिचान समस्या लुकाउँछ।

पूर्ण टनेल र साँघुरो फर्वार्डिङबीचको छनोट सुरक्षा-नाटक होइन, दायराको निर्णय हो।

पछाडि दोहोर्याउन सकिने बाटो छोड्नुहोस्

समाधान गरिएको ठेगानाको सट्टा अन्त्यबिन्दुको नाम, सुरक्षा समूहले अनुमति दिने स्रोत दायरा, र विकासकर्ताले प्रयोग गर्ने डेटाबेस भूमिका अभिलेख गर्नुहोस्। यी तीन तथ्यले भविष्यका अधिकांश असफलता फोनबिना व्याख्या गर्छन्। क्लाइन्ट प्रोफाइलको संस्करण पनि थप्नुहोस्, किनकि प्रोफाइल परिवर्तनले पुरानोले बोकेको मार्ग हटाउन सक्छ।

त्यसपछि नकारात्मक केस एकपटक परीक्षण गर्नुहोस्: स्वीकृत स्रोतबाहिरको क्लाइन्ट अझै अस्वीकार हुनुपर्छ।

जुन निजी डेटाबेस केवल त्यसैले सेट गरेको व्यक्तिका लागि मात्र चल्छ त्यो निजी पहुँच होइन; त्यो फेरि पत्ता लाग्न बाँकी अभिलेख नगरिएको अपवाद हो। बाटो लेख्नुहोस्, र अर्को विकासकर्ताले रहस्यको सट्टा विधि उत्तराधिकारमा पाउनेछ।