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 चाचणी उत्तीर्ण होते.

स्तर लोड झाल्यावर प्रकल्प फक्त फाइलांसाठी सापेक्ष मार्गांसह जतन करा आणि सेवा जोडण्या त्यांच्या एंडपॉइंटच्या नावाने ठेवा. प्रकल्प वारसा मिळणारी पुढील व्यक्ती तिकीट न उघडता तुटलेल्या स्तराला कोणत्या होस्टची अपेक्षा होती हे सांगू शकेल.