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 ભૂલ દેખાય ત્યારે લોકો બંધ કરે છે તે જ ભાગ છે.
જો મંજૂર કરેલો એન્ડપોઇન્ટ પૂલર પાછળ હોય, તો પોર્ટ 6432 અને પોર્ટ 5432 જુદી જુદી સર્વર ઓળખ દ્વારા એ જ ડેટા સુધી પહોંચી શકે છે, અને ચકાસણી ડેટાબેઝના નામને બદલે પૂલરના નામ પર નિષ્ફળ થઈ શકે છે. મોડ નબળો કરવાને બદલે કનેક્શન સ્ટ્રિંગમાં નામ સુધારો.
આગળનું પગલું ભૂલ સંદેશને પસંદ કરવા દો
નિષ્ફળતાનું લખાણ કહે છે કે પ્રયાસ કેટલો દૂર ગયો, અને તે ટનલ વિશેના કોઈ પણ અનુમાનને હરાવે છે. જે નામ ઉકેલાતું નથી તે સોકેટ અસ્તિત્વમાં આવે તે પહેલાં નિષ્ફળ જાય છે, સમયસીમા એટલે માર્ગ કે ફાયરવોલે પેકેટ ફેંક્યા, નકાર એટલે કંઈકે જવાબ આપીને મના કરી, અને પ્રમાણીકરણ ભૂલ એટલે નેટવર્ક પહેલેથી કામ કરતું હતું.
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 પાસે સમજાવવા માટે કંઈ બચતું નથી. જ્યાં સુધી તેઓ ન મળે, ત્યાં સુધી ટનલમાં દરેક વધારાનો ફેરફાર એવા કનેક્શન વિશે અનુમાન છે જે ટર્મિનલે ક્યારેય કર્યું નથી.