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 च्या आतून अपयशी होते। हे तीन निष्कर्ष नेटवर्क सीमेला डेटाबेस अधिकृतीपासून वेगळे करतात, आणि निर्णय वेगळे ठेवण्याचा संपूर्ण हेतू तोच आहे।