VPN ले psql लाई रोक्दैन: तपाईंको क्लाइन्ट अन्तै डायल गर्दैछ
psql र GUI क्लाइन्ट एउटै मेसिनबाट फरक अन्त्यबिन्दुमा डायल गर्न सक्छन्। VPN लाई दोष दिनुअघि होस्ट, सकेट, भूमिका र TLS तुलना गर्नुहोस्।
दुवै क्लाइन्ट एउटै ल्यापटपमा छन्, एउटै टनेलबाट जान्छन्, र तीमध्ये एउटा मात्र जोडिन्छ। त्यो तुलना VPN छनोट गर्ने छ भन्ने प्रमाणजस्तो लाग्छ, तर धेरै सामान्य व्याख्या दुई क्लाइन्ट फरक फरक गन्तव्यमा डायल गर्छन् भन्ने हो। एउटा GUI आफ्नै होस्ट, पोर्ट, भूमिका र TLS सेटिङ राख्छ र आवश्यक पर्दा चुपचाप SSH फर्वार्ड बनाउँछ, जबकि psql तपाईंको शेलले पहिले नै सेट गरेको हुनसक्ने libpq पूर्वनिर्धारित मानहरूबाट जडान जोड्छ। काम गर्ने जडान पुनः उत्पादन गर्नु GUI का सेटिङ पढ्ने कुरा हो, टनेल पुनः स्थापना गर्ने होइन।
किंवदन्ती: एउटा काम गर्ने क्लाइन्टले बाटो प्रमाणित गर्छ
GUI जोडियो भने टनेलले ट्राफिक बोक्छ, र GUI ले प्रमाणित गर्ने त्यत्ति मात्र हो। psql कुन ठेगाना समाधान गर्छ, कुन भूमिकाले प्रमाणीकरण गर्छ, वा यसले खोल्ने सकेट कहिल्यै मेसिनबाट बाहिर जान्छ कि जाँदैन भन्ने कुरा यसले भन्दैन। बाटो साझा छ; प्यारामिटर छैनन्।
स्थानीय फर्वार्डले फरक फराकिलो बनाउँछ। GUI ले SSH मार्फत फर्वार्ड गरेको पोर्टमा 127.0.0.1 मा जोडिन सक्छ, र त्यो श्रोता GUI सत्र चल्ने बेलासम्म मात्र हुन्छ। फर्वार्ड बिना localhost तर्फ देखाइएको psql ले VPN सँग कुनै सम्बन्ध नभएको अस्वीकृत जडान पाउँछ।
GUI ले वास्तवमा प्रयोग गर्ने अन्त्यबिन्दु पढ्नुहोस्
जडानका गुणहरू खोलेर चार मान प्रतिलिपि गर्नुहोस्: होस्ट, पोर्ट, डाटाबेस र भूमिका। त्यसपछि टनेल ट्याब खोज्नुहोस्, किनकि SSH फर्वार्डले निजी ठेगानालाई स्थानीय पोर्टमा बदल्छ र psql लाई के भन्नुपर्ने हो त्यो बदल्छ।
| Setting | What the GUI holds | What psql uses when the value is absent |
|---|---|---|
| Destination | A saved hostname, sometimes behind a forward | A local Unix socket, not the remote endpoint |
| Port | The direct port or a forwarded local port | 5432, or the port from a service file |
| Role and database | Stored per connection profile | Your operating-system user name |
| TLS identity | Its own CA bundle and verification mode | Whatever PGSSLMODE or the service file says |
| Startup files | Not read at all | Read unless -X is passed |
हरेक पङ्क्ति फरक तहमा असफल हुन्छ, र तपाईंले पाउने सन्देशले त्यही तहको नाम लिन्छ। सुरक्षित प्रोफाइलको मिलनसार नाम psql मा टाँस्दा माथिका कुनै पनि मान जाँदैन, र सेवाको नाम टर्मिनलले कहिल्यै नपढ्न सक्ने फाइलमार्फत समाधान हुन्छ।
libpq ले तपाईंको शेलबाट के उत्तराधिकारमा पाउँछ
psql libpq माथिको पातलो क्लाइन्ट हो, र libpq अरू केही पढ्नुअघि वातावरण पढ्छ। PGHOST, PGHOSTADDR, PGPORT, PGDATABASE, PGUSER, PGSERVICE र PGSSLMODE जस्ता चलहरूले प्रत्येकले जडानको केही भाग अन्यत्र मोड्न सक्छन्। ती टाइप गरिनुको सट्टा उत्तराधिकारमा आउँछन्, त्यसैले तपाईंले चलाएको आदेशमा कुनैले पनि तिनीहरू देखाउँदैन। निर्यात गरिएको PGSSLMODE ले पनि आदेश लाइनमा एक शब्द नबोली क्लाइन्टले के स्वीकार्छ त्यो बदल्न सक्छ।
तीमध्ये दुई चल पहिले शङ्काका पात्र छन्। PGHOSTADDR नाम समाधानलाई जित्ने सङ्ख्यात्मक गन्तव्य दिन्छ, जबकि होस्टनामले अझै प्रमाणपत्रको पहिचान तय गर्छ, र PGSERVICE ले सेवा फाइलबाट होस्ट, डाटाबेस र TLS विकल्प तान्छ। यो डिबग गर्न सम्पूर्ण वातावरण डम्प गर्नु खराब बानी हो, किनकि त्यसमा पासवर्ड र असम्बन्धित टोकन हुन सक्छन्; बरु तपाईंलाई चासो लाग्ने चलहरू छान्नुहोस्।
host र hostaddr दुवै छोड्दा नेटवर्क ठेगानाको सट्टा Unix डोमेन सकेट छानिन्छ। त्यसैले -h बिना psql कल स्थानीय रूपमा सफल हुन सक्छ, वा सकेट त्रुटिले असफल हुन सक्छ, GUI ले प्रयोग गर्ने मार्गलाई कहिल्यै नछुँदै।
तीही प्यारामिटर हातले पठाउनुहोस्
GUI का मान हातमा भएपछि तिनलाई स्पष्ट रूपमा पठाउनुहोस् र ओभरराइड थप्न सक्ने सुरु फाइल छोड्नुहोस्। तलको जडान स्ट्रिङ उदाहरण हो: अन्त्यबिन्दु, पोर्ट, डाटाबेस र भूमिका तपाईंको प्रशासकले स्वीकृत गरेका मानहरूले बदल्नुहोस्, र पहिले नै काम गरिरहेको विश्वास कन्फिगरेसन राख्नुहोस्।
psql -X "host=db.internal.example port=6432 dbname=orders user=report_ro sslmode=verify-full connect_timeout=5"त्यो आदेशका तीन विवरण जानाजानका हुन्। -X ले psql को सुरु फाइल दबाउँछ, तर libpq को वातावरण वा सेवा परिभाषा दबाउँदैन। connect_timeout=5 ले खाली मार्गले टर्मिनललाई मिनेटौं झुन्ड्याउनबाट रोक्छ। sslmode=verify-full ले प्रमाणपत्र र होस्टनाम जाँच सक्रिय राख्छ, र TLS त्रुटि देखा पर्दा मानिसहरूले ठ्याक्कै यही भाग बन्द गर्छन्।
स्वीकृत अन्त्यबिन्दु कुनै pooler पछाडि छ भने पोर्ट 6432 र पोर्ट 5432 फरक सर्भर पहिचानमार्फत एउटै डाटामा पुग्न सक्छन्, र प्रमाणीकरण डाटाबेसको नाममा नभई pooler को नाममा असफल हुन सक्छ। मोड कमजोर बनाउनुको सट्टा जडान स्ट्रिङमा नाम सुधार्नुहोस्।
अर्को कदम त्रुटि सन्देशले छानोस्
असफलताको पाठले प्रयास कति टाढा पुग्यो भन्छ, र त्यो टनेलबारे कुनै पनि अनुमानभन्दा राम्रो हो। समाधान नहुने नाम सकेट बन्नुअघि नै असफल हुन्छ, समय समाप्त हुनु भनेको मार्ग वा फायरवालले प्याकेट खसाल्यो, अस्वीकार भनेको केहीले जवाफ दिएर मानेन, र प्रमाणीकरण त्रुटि भनेको नेटवर्क पहिले नै काम गरिरहेको थियो।
psql -X -w "host=db.internal.example port=6432 dbname=orders user=report_ro sslmode=verify-full connect_timeout=5" -c '\conninfo'
env | grep -E '^PG'
psql --version\conninfo को आउटपुट GUI को जीवित सत्रसँग तुलना गर्नुहोस्: एउटै होस्ट, एउटै पोर्ट, एउटै भूमिका, एउटै TLS अवस्था। यी चार मिलेपछि VPN सँग व्याख्या गर्न बाँकी केही रहँदैन। नमिलेसम्म टनेलमा गरिने हरेक थप परिवर्तन टर्मिनलले कहिल्यै नबनाएको जडानबारे अनुमान हो।