स्थानिक डेटाबेस क्लायंट आणि खाजगी 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 पडताळणी अभंग ठेवा। क्लायंटने अपेक्षित नावाशी सर्व्हर प्रमाणपत्राची पडताळणी अजूनही करावी; स्थानिक फॉरवर्ड केलेला पोर्ट पडताळणी बंद करण्याचे कारण नाही, आणि ती बंद केल्याने पकडण्यासारखीच ओळखीची समस्या लपते।

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

मागे पुनरावृत्ती करण्याजोगा मार्ग सोडा

सोडवलेल्या पत्त्याऐवजी एंडपॉइंटचे नाव, सुरक्षा गट परवानगी देतो ती स्रोत श्रेणी, आणि विकसक वापरतो ती डेटाबेस भूमिका नोंदवा। ही तीन तथ्ये भविष्यातील बहुतेक अपयशे फोनशिवाय स्पष्ट करतात। क्लायंट प्रोफाइलची आवृत्तीही जोडा, कारण प्रोफाइल बदल जुन्याने वाहून नेलेला मार्ग काढून टाकू शकतो।

मग नकारात्मक प्रकरण एकदा तपासा: मंजूर स्रोताबाहेरील क्लायंटला अजूनही नकार द्यायला हवा।

जो खाजगी डेटाबेस फक्त तो सेट करणाऱ्या व्यक्तीसाठीच चालतो तो खाजगी प्रवेश नाही; तो पुन्हा शोधला जाण्याची वाट पाहणारा नोंद न केलेला अपवाद आहे। मार्ग लिहून ठेवा, आणि पुढचा विकसक कोडे नाही तर पद्धत वारसाने घेईल।