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 कडे स्पष्ट करण्यासारखे काही उरत नाही। ते जुळेपर्यंत टनेलमधील प्रत्येक अतिरिक्त बदल हा टर्मिनलने कधीच न केलेल्या कनेक्शनबद्दलचा अंदाज आहे।