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 कलले QGIS ले विश्लेषण गर्ने क्षमता XML फर्काउँछ, त्यसैले त्यो आउटपुटमा HTML लगइन पृष्ठले खाली तह तुरुन्तै व्याख्या गर्छ।

समय समाप्तिको तुलनामा PostgreSQL त्रुटि राम्रो समाचार हो। यसले गन्तव्यले जवाफ दिएको प्रमाणित गर्छ, जसले टिकटलाई सञ्जाल टोलीबाट डेटाबेस वा GIS प्रशासककडे सार्छ। प्रतिवेदनमा यो भिन्नता राख्नुले एउटा चक्कर बचाउँछ।

परियोजना खाली तहहरूसँग खुल्दा

QGIS भित्र, केही पुनः प्रविष्ट गर्नुअघि तहको सुरक्षित स्रोत जाँच्नुहोस्। तहका गुणहरूले परियोजनाले सुरक्षित गरेको ठ्याक्कै जडान शृंखला देखाउँछन्, र पुरानो होस्टसहितको दोहोरो जडान प्रविष्टि अघिल्लो कार्यालय सञ्जालको सामान्य अवशेष हो। जडान सुधारेपछि परियोजना पुनः लोड गर्दा प्रदायक सधैं पुनः पढिँदैन, त्यसैले तह हटाउनुहोस् र सुधारिएको जडानबाट फेरि थप्नुहोस्।

त्यसपछि प्रमाणीकरण कन्फिगरेसन तहसँग जोडिएको हो, केवल सूचीमा रहेको होइन भनी पुष्टि गर्नुहोस्। अर्को प्रमाणीकरण कन्फिगरेसनसँग सुरक्षित गरिएको तह ब्राउजर प्यानलमा चुपचाप असफल हुन्छ, जबकि स्वतन्त्र psql परीक्षण उत्तीर्ण हुन्छ।

तह लोड भएपछि परियोजना फाइलहरूका लागि मात्र सापेक्ष मार्गसहित सुरक्षित गर्नुहोस् र सेवा जडानहरू तिनका इन्डपोइन्टको नाममा राख्नुहोस्। परियोजना उत्तराधिकारमा पाउने अर्को व्यक्तिले टिकट नखोलीकन कुन होस्ट अपेक्षा गरिएको थियो भन्न सक्नेछ।