QGIS PostGIS SSH सुरुङ: TLS का लागि सर्भरको नाम राख्नुहोस्

सुरुङ माथि आउँछ, QGIS जोडिन्छ, र लगइन डेटाबेस होस्टको सट्टा 127.0.0.1 नाम दिने प्रमाणपत्र त्रुटिसँग मर्छ। अर्को लोभ्याउने कदम sslmode लाई ढिलो बनाउनु हो, जसले जाँचलाई शान्त पार्छ र तपाईं सुरुदेखि नै चाहनुभएको पहिचानको ग्यारेन्टी फालिदिन्छ। वास्तविक समस्या यो हो कि स्थानीय पोर्ट र सर्भरको नाम एउटै फिल्डमा राखिन्छ। libpq सेवा प्रविष्टिले तिनीहरूलाई अलग गर्छ, त्यसैले सकेट फर्वार्ड गरिएको पोर्टमा जान्छ जबकि TLS अझै प्रमाणपत्रमा छापिएको नाम प्रमाणित गर्छ।

क्लाइन्टले केमा जोडिएको ठान्छ

sslmode=verify-full अन्तर्गत libpq ले सर्भरले प्रस्तुत गर्ने प्रमाणपत्रलाई मागिएको होस्ट नामसँग तुलना गर्छ। त्यो नाम loopback ठेगाना भएमा प्रमाणपत्र वास्तविक डेटाबेस होस्टका लागि मान्य भए पनि तुलना असफल हुन्छ। SSH फर्वार्डले कुन सकेटले बाइट बोक्छ भन्ने बदल्छ, क्लाइन्टले अपेक्षा गर्नुपर्ने पहिचान होइन। ती दुई विचार अलग भएपछि त्रुटि अब TLS खराबीजस्तो देखिँदैन।

फर्वार्ड अनुमति पनि होइन। PostgreSQL ले SSH सर्भरले बनाउने जडानमा अझै आफ्नै नियम लागू गर्छ, त्यसैले केही बदल्नुअघि ढुवानी तह र डेटाबेस तह अलग राख्नुहोस्।

फर्वार्डलाई loopback मा मात्र बाँध्नुहोस्

श्रोता QGIS मेसिनमै हुनुपर्छ, अरू कतै पनि हुँदैन। 127.0.0.1 स्पष्ट रूपमा उल्लेख गर्दा यसलाई अन्य इन्टरफेसबाट टाढा राखिन्छ, तर बाइन्ड ठेगाना छोड्दा SSH क्लाइन्टको गेटवे सेटिङअनुसार पोर्ट बाहिर खुल्न सक्छ।

ssh -N -L 127.0.0.1:15432:127.0.0.1:5432 [email protected]

दोस्रो कोलनपछिको गन्तव्य SSH सर्भरको पक्षबाट समाधान हुन्छ, त्यसैले यो उदाहरणले PostgreSQL sshd भएको उही होस्टमा छ भनी मान्छ; अर्को मेसिनको डेटाबेसलाई त्यो ठेगाना र त्यसका अनुमतिहरू चाहिन्छ। सत्र -N सहित सुरु गर्नुहोस् ताकि कुनै शेल नखुलोस्, होस्ट-की प्रमाणीकरणलाई छुनु हुँदैन, र QGIS लाई दोष दिनुअघि श्रोता देखा परेको पुष्टि गर्नुहोस्। पोर्ट पहिले नै प्रयोगमा छ भने फर्वार्ड क्वेरीको समयमा होइन, सुरुमै असफल हुन्छ।

नाम र सकेटलाई एउटै सेवा प्रविष्टिमा राख्नुहोस्

सेवा फाइलले एउटै जडानलाई प्रमाणीकरण नाम र फरक सकेट गन्तव्य बोक्न दिन्छ। प्रविष्टि जहाँ libpq ले सेवाहरू खोज्छ त्यहीँ सुरक्षित गर्नुहोस्, वा PGSERVICEFILE लाई त्यतातिर निर्देश गर्नुहोस्।

[gis-via-ssh]
host=db.geo.example
hostaddr=127.0.0.1
port=15432
dbname=gisdb
user=gis_reader
sslmode=verify-full
gssencmode=disable
sslrootcert=/path/to/approved-root.crt

यहाँ host ले प्रमाणपत्र जाँचका लागि प्रयोग हुने पहिचान राख्छ भने hostaddr ले प्याकेटहरू फर्वार्ड गरिएको loopback पोर्टमा पठाउँछ, र यो व्यवस्था काम गर्न दुवै आवश्यक छन्। gssencmode=disable अन्यथा पहिले GSSAPI इन्क्रिप्शनमा वार्ता गर्ने बिल्डहरूमा महत्त्वपूर्ण छ, किनकि त्यो मार्गले भर्खरै सेट गरिएका TLS सेटिङहरू बेवास्ता गर्छ। QGIS को PostgreSQL जडान संवादबाट नामद्वारा सेवाको सन्दर्भ दिनुहोस् र पासवर्ड साझा फाइलभित्र होइन, सामान्य प्रम्प्टमार्फत दिनुहोस्। माथिका नाम र बाटा प्लेसहोल्डर हुन्; तिनलाई आफ्नै स्वीकृत मानहरूले बदल्नुहोस्।

सुरुङपछि PostgreSQL ले अझै के जाँच्छ

सर्भरले SSH होस्टबाट, यो व्यवस्थामा loopback बाट, आउने जडान देख्छ र क्रमैले होस्ट-आधारित प्रमाणीकरण नियमहरूसँग भिडाउँछ। तपाईंको डेटाबेस भूमिकाले अझै प्रमाणीकरण गर्नुपर्छ, र SSH लगइनले आफैंमा कुनै डेटाबेस पहिचान दिँदैन। क्लाइन्टले मानेको कुरा होइन, सर्भरले के विश्वास गर्छ त्यो प्रमाणित गर्नुहोस्।

psql "service=gis-via-ssh" -c "select inet_server_addr(), current_user"

काम सकिएपछि फर्वार्डिङ सत्र बन्द गर्नुहोस्; स्थानीय प्रविष्टि त्यसपछि काम गर्न छोड्छ र अरू केही बदलिँदैन। डेटाबेसको एउटा मार्ग सम्पूर्ण GIS क्लाइन्टका लागि VPN होइन, र यसलाई VPN ठान्नु नै अर्को जडानको गलत निदान हुनुको कारण हो।