VPN के पीछे QGIS को PostGIS से जोड़ें: चरण दर चरण

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

VPN से नहीं, परत से शुरू करें

हर परत प्रकार भिन्न प्रकार के एंडपॉइंट तक पहुँचता है। PostGIS परत होस्ट, पोर्ट, डेटाबेस और भूमिका के साथ PostgreSQL कनेक्शन खोलती है। WMS या WFS परत सेवा URL लाती है और फिर क्षमता दस्तावेज़ का विश्लेषण करती है। नेटवर्क शेयर पर रखी shapefile को केवल उस फ़ाइल पथ की जरूरत होती है जिसे ऑपरेटिंग सिस्टम खोल सके। चूँकि ये तीन भिन्न तंत्र हैं, खाली परियोजना आपको कुछ नहीं बताती जब तक आप न जानें कि किसे डीबग कर रहे हैं।

GIS ऑपरेटर से एंडपॉइंट, पोर्ट, आवश्यक पहचान और आपके खाते पर लागू पहुँच नीति पूछें। जब तैनाती निजी DNS या प्रमाणपत्र में नाम-जाँच पर निर्भर हो तो सेवा होस्टनाम को ठीक वैसा ही रखें जैसा जारी किया गया था। किसी अन्य उपयोगकर्ता के सहेजे गए कनेक्शन से नकल किया गया होस्ट पता दोबारा इस्तेमाल करना उस मशीन तक पहुँचने का सबसे तेज़ रास्ता है जो जवाब देती है पर पुराना डेटाबेस रखती है।

रूट, अनुमत संसाधन और नाम-समाधान VPN चलाने वाले के होते हैं। डेटा-स्रोत फ़ॉर्म ऐसा रूट नहीं लगा सकता जो टनल प्रोफ़ाइल ने कभी नहीं भेजा, और वह गेटवे नीति को चौड़ा नहीं कर सकता। जब होस्ट हल हो जाए और पोर्ट जवाब दे, तो समस्या का नेटवर्क पक्ष समाप्त है।

ऑपरेटर द्वारा जारी निजी एंडपॉइंट दर्ज करें

QGIS में PostgreSQL फ़ॉर्म वे फ़ील्ड दिखाता है जिनकी libpq अपेक्षा करता है, इसलिए इसे उसी क्रम में भरें जिस क्रम में कमांड-लाइन कनेक्शन भरता। सेवा और होस्ट डेटाबेस मशीन लेते हैं, पोर्ट वह श्रोता लेता है जो सर्वर वास्तव में खोलता है, और डेटाबेस सर्वर के डिफ़ॉल्ट के बजाय विशिष्ट कैटलॉग लेता है। पासवर्ड को परियोजना फ़ाइल में नहीं, प्रमाणीकरण कॉन्फ़िगरेशन में रखें, ताकि साझा परियोजना कोई क्रेडेंशियल न ढोए।

कुछ भी टाइप करने से पहले दोनों नाम अलग करें। गेटवे का नाम VPN क्लाइंट में जाता है और डेटाबेस का नाम QGIS में, और ये शायद ही एक ही होस्ट हों।

VPN gateway:   vpn.gis.lab.example       (profile only, not a data source)
Database host: db.gis.lab.example:5432   (PostGIS service)
Database name: gis_prod
TLS mode:      verify-full

यदि डेटाबेस गेटवे के पीछे किसी दूसरी मशीन पर है, तो फ़ॉर्म में नाम वही मशीन होना चाहिए। टनल के माध्यम से निजी DNS ही नाम को काम कराता है, और जो परियोजना केवल कनेक्ट रहने पर हल होती है वह खराब कैश करने के बजाय सही व्यवहार कर रही है।

डेटाबेस के TLS मोड को टनल से अलग रखें

VPN उत्पाद के नाम में SSL टनल का वर्णन करता है, डेटाबेस सत्र का नहीं। QGIS PostgreSQL SSL मोड libpq को देता है, और वही मोड तय करता है कि क्लाइंट सर्वर का प्रमाणपत्र सत्यापित करता है या नहीं और उसमें मौजूद होस्टनाम जाँचता है या नहीं। verify-fullदोनों करता है, इसलिए जब प्रमाणपत्र में सेवा का नाम हो तो यही मोड रखने योग्य है।

मोड को disable तक घटाना, क्योंकि टनल पहले से एन्क्रिप्टेड है, यह जाँच हटा देता है कि आप जिस सर्वर तक पहुँचे वही सर्वर है जिसका आपने अनुरोध किया। जब सत्यापन विफल हो, सामान्य कारण नाम का मेल न खाना या मूल प्रमाणपत्र का अनुपस्थित होना है, और दोनों कनेक्शन को कमजोर किए बिना ठीक किए जा सकते हैं। sslrootcert को ऑपरेटर द्वारा प्रकाशित CA की ओर इंगित करें और फ़ॉर्म में होस्टनाम को प्रमाणपत्र के नाम के समान रखें.

निजी रूट वाली टनल और वैध प्रमाणपत्र वाला डेटाबेस फिर भी भूमिका पर विफल हो सकते हैं। एप्लिकेशन क्रेडेंशियल VPN क्रेडेंशियल से अलग हैं, और गेटवे पर प्रमाणित खाते को PostgreSQL में कोई निहित अधिकार नहीं होता।

हर सीमा क्रम में जाँचें और पहली विफलता पढ़ें

क्लाइंट से बाहर की ओर एक निश्चित क्रम में काम करें: नाम-समाधान, TCP पहुँच, TLS, प्रमाणीकरण और फिर प्रश्न स्वयं। पहला विफल चरण ही रिपोर्ट करने योग्य है, और आगे छलांग लगाने से ऐसी सीमा के त्रुटि संदेश आते हैं जहाँ आप अभी नहीं पहुँचे। चार आदेश पहले चार चरणों को कवर करते हैं।

getent hosts db.gis.lab.example
nc -vz db.gis.lab.example 5432
psql "host=db.gis.lab.example port=5432 dbname=gis_prod sslmode=verify-full" -c 'select 1'
curl -sS 'https://wms.gis.lab.example/ows?service=WMS&request=GetCapabilities' | head -c 200

getent से खाली उत्तर नाम-समाधान समस्या है, डेटाबेस समस्या नहीं। अस्वीकृत या समय-समाप्त nc का अर्थ है कि रूट या firewall नियम गायब है, जो गेटवे पक्ष का सुधार है। psql से TLS त्रुटि का अर्थ है कि प्रमाणपत्र या नाम गलत है, जबकि password authentication failed का अर्थ है कि आप PostgreSQL तक पहुँचे और समस्या क्रेडेंशियल है। WMS परत के लिए, curl कॉल वह क्षमता XML लौटाता है जिसे QGIS विश्लेषित करता, इसलिए उस आउटपुट में HTML लॉगिन पृष्ठ खाली परत को तुरंत समझाता है।

समय-समाप्ति की तुलना में PostgreSQL त्रुटि अच्छी खबर है। यह सिद्ध करती है कि गंतव्य ने जवाब दिया, जो टिकट को नेटवर्क टीम से डेटाबेस या GIS प्रशासक की ओर भेजता है। रिपोर्ट में यह अंतर बनाए रखना एक चक्कर बचाता है।

जब परियोजना खाली परतों के साथ खुलती है

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

फिर पुष्टि करें कि प्रमाणीकरण कॉन्फ़िगरेशन वही है जो परत से जुड़ा है, केवल सूची में मौजूद नहीं। दूसरे प्रमाणीकरण कॉन्फ़िगरेशन के साथ सहेजी गई परत ब्राउज़र पैनल में चुपचाप विफल होती है, जबकि स्वतंत्र psql परीक्षण पास होता है।

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