स्थानीय डेटाबेस क्लाइंट और निजी 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 सत्यापन अक्षुण्ण रखें। क्लाइंट को अब भी सर्वर प्रमाणपत्र को उस नाम के विरुद्ध सत्यापित करना चाहिए जिसकी वह अपेक्षा करता है; स्थानीय फ़ॉरवर्ड किया पोर्ट सत्यापन बंद करने का कारण नहीं है, और उसे बंद करना ठीक उसी पहचान समस्या को छिपा देता है जिसे पकड़ना ज़रूरी है।

पूरी टनल और संकीर्ण फ़ॉरवर्डिंग के बीच चुनाव दायरे का फ़ैसला है, सुरक्षा-नाटक का नहीं।

पीछे एक दोहराया जा सकने वाला रास्ता छोड़ें

हल किए पते की जगह एंडपॉइंट का नाम, सुरक्षा समूह जो स्रोत रेंज अनुमति देता है, और डेवलपर जो डेटाबेस भूमिका इस्तेमाल करता है, इन्हें दर्ज करें। ये तीन तथ्य भविष्य की ज़्यादातर विफलताएँ बिना कॉल के समझा देते हैं। क्लाइंट प्रोफ़ाइल का संस्करण भी जोड़ें, क्योंकि प्रोफ़ाइल बदलाव पुरानी के ढोए रूट को हटा सकता है।

फिर नकारात्मक स्थिति एक बार जाँचें: स्वीकृत स्रोत के बाहर का क्लाइंट अब भी अस्वीकार होना चाहिए।

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