VPN के ज़रिए PostgreSQL: pg_hba कौन-सा स्रोत पता देखेगा

PostgreSQL को कभी पता नहीं चलता कि कोई क्लाइंट VPN पर है। उसे किसी पते से एक TCP कनेक्शन और क्रेडेंशियल का एक सेट मिलता है, और वह तय करता है कि उनके साथ क्या करना है। इसलिए एक्सेस को टनल पर निर्भर बनाने का अर्थ है तीन अलग निर्णयों को इस तरह व्यवस्थित करना कि वे सहमत हों, और फिर आरेख पर खींचे गए पते के बजाय उस एक पते की जाँच करना जो सर्वर वास्तव में देखता है।

तीन निर्णय जिन्हें मिलाया नहीं जाना चाहिए

सर्वर कहाँ सुनता है, यह एक निर्णय है। कौन-सा ट्रैफ़िक उस पते तक पहुँच सकता है, यह दूसरा है, जो होस्ट फ़ायरवॉल और उसके सामने की किसी भी नेटवर्क सीमा द्वारा लिया जाता है। कौन-सी डेटाबेस पहचान किस स्रोत से प्रमाणित हो सकती है, यह तीसरा है, जो pg_hba.conf में लिया जाता है।

इनमें से प्रत्येक को एक अलग घटक लागू करता है, और प्रत्येक एक अलग संदेश के साथ विफल होता है। इन्हें किसी चर्चा में मिलाना ही वह तरीका है जिससे लोग फ़ायरवॉल समस्या ठीक करने के लिए HBA फ़ाइल संपादित करने लगते हैं। इन्हें क्रम में रखें: जो लिसनर बाध्य नहीं है उस तक पहुँचा नहीं जा सकता, फ़िल्टर किए गए पोर्ट से जुड़ा नहीं जा सकता, और HBA नियम केवल यह तय करता है कि कनेक्शन होने के बाद क्या होगा। जब किसी बदलाव का कोई प्रभाव न हो, तो पहचानें कि आपने वास्तव में तीन में से कौन-सी परत बदली है।

सर्वर कहाँ सुनता है

उस पते पर बाइंड करें जो वास्तव में मशीन को दिया गया है, किसी इंटरफ़ेस नाम पर नहीं:

listen_addresses = '10.20.0.30'

डेटाबेस अपने स्वयं के टनल इंटरफ़ेस के बिना VPN गेटवे के पीछे बैठ सकता है, और ठीक इसी कारण पता ही वह सही चीज़ है जिसे नाम दिया जाना चाहिए। इस सेटिंग को बदलने के लिए पूर्ण पुनःआरंभ चाहिए; पुनःलोड पर्याप्त नहीं है।

फिर पोर्ट, आमतौर पर 5432, को होस्ट पर और उसके सामने की हर सीमा पर फ़िल्टर करें। निजी पते पर बाइंड करना सार्वजनिक अस्वीकृति का प्रमाण नहीं है, क्योंकि पोर्ट फ़ॉरवर्ड या क्लाउड पता मैपिंग अब भी उस निजी लिसनर तक पैकेट पहुँचा सकती है।

वह पता जो HBA वास्तव में देखता है

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

उस परिनियोजन के लिए जो पहले से TLS और SCRAM का उपयोग करता है, जानबूझकर संकीर्ण दूरस्थ-एक्सेस उदाहरण ऐसा दिखता है:

hostssl appdb app_login 10.8.0.0/24 scram-sha-256
host all all 0.0.0.0/0 reject
host all all ::/0 reject

यह बताए गए पूल से TLS पर एक भूमिका और एक डेटाबेस की अनुमति देता है, फिर अन्य दूरस्थ TCP एक्सेस को अस्वीकार करता है। यह पूर्ण HBA फ़ाइल का विकल्प नहीं है: स्थानीय प्रशासन, प्रतिकृति और किसी भी अन्य अधिकृत सेवा को रखें, और संकीर्ण नियमों को व्यापक अनुमतियों से पहले रखें।

जब अनुवाद चल रहा हो, HBA क्लाइंट को उनके मूल पतों से अलग नहीं कर सकता। नेटवर्क प्रवेश कड़ा रखें और वास्तविक डेटाबेस क्रेडेंशियल माँगें, और कभी भी trust प्रमाणीकरण को वास्तविक खाते से न बदलें।

पहला मेल जीतता है, बिना किसी विकल्प के

PostgreSQL फ़ाइल को ऊपर से नीचे पढ़ता है और कनेक्शन से मेल खाने वाला पहला रिकॉर्ड उपयोग करता है। यदि उस रिकॉर्ड का प्रमाणीकरण विफल हो जाए तो दूसरा प्रयास नहीं है, इसलिए पहले की व्यापक अनुमति बाद की अस्वीकृति को चुपचाप हरा देती है।

यह क्रम-नियम ही सबसे आम कारण है कि ध्यान से लिखी गई अस्वीकृति कभी प्रभावी नहीं होती। विशिष्ट नियम पहले और व्यापक अंत में रखें, फिर फ़ाइल को समुच्चय के बजाय क्रम के रूप में पढ़ें। नीचे जोड़ा गया नियम नीति नहीं है, वह टिप्पणी है। फ़ाइल को अनदेखा किया जा रहा है ऐसा निष्कर्ष निकालने से पहले उसे ऊपर ले जाएँ और पुनःलोड करें।

HBA संदर्भ क्रम और host तथा hostssl रिकॉर्ड के बीच का अंतर दोनों परिभाषित करता है, जो तब मायने रखता है जब नियम का उद्देश्य यह हो कि कनेक्शन एन्क्रिप्टेड होना चाहिए।

पुनःलोड, पुनःआरंभ और अस्वीकृत मामला

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

लिसनर परिवर्तनों को अपने स्वयं के पुनःआरंभ की आवश्यकता होती है, और जब किसी बदलाव का कोई प्रभाव न दिखे तो दोनों क्रियाओं में भ्रम होना आसान है।

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