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 मान लेना ही अगले कनेक्शन का गलत निदान होने की वजह है।