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 भित्रबाट असफल हुन्छ। ती तीन परिणामहरूले सञ्जाल सीमालाई डेटाबेस अधिकारबाट अलग गर्छन्, र निर्णयहरू अलग राख्नुको पूरै उद्देश्य त्यही हो।