Die VPN blokkeer nie psql nie: jou kliënt skakel elders in
psql en 'n GUI-kliënt kan verskillende eindpunte van een masjien aandui. Vergelyk gasheer, sokkel, rol en TLS voordat jy die VPN blameer.
Albei kliënte sit op dieselfde skootrekenaar, gaan deur dieselfde tonnel, en net een van hulle maak verbinding. Hierdie vergelyking voel soos bewys dat die VPN selektief is, terwyl die veel algemener verklaring is dat die twee kliënte verskillende bestemmings aandui. 'n GUI hou sy eie gasheer, poort, rol en TLS-instellings en bou stilweg 'n SSH-deurvoer wanneer hy een nodig het, terwyl psql 'n verbinding saamstel uit libpq-verstekke wat jou dop reeds gestel het. Om die werkende verbinding te herproduseer is 'n kwessie van die GUI se instellings lees, nie van die tonnel herinstalleer nie.
Die mite: een werkende kliënt bewys die pad
As die GUI verbind, dra die tonnel verkeer, en dit is die enigste ding wat die GUI bewys. Dit sê niks oor watter adres psql oplos, as watter rol dit authentiseer, of of die sokkel wat dit oopmaak ooit die masjien verlaat nie. Die pad is gedeel; die parameters is nie.
'n Plaaslike deurvoer vergroot die gaping. Die GUI kan aan 127.0.0.1 koppel op 'n poort wat hy oor SSH deurgevoer het, en daardie luisteraar bestaan net vir die duur van die GUI-sessie. psql wat na localhost wys sonder die deurvoer, kry 'n geweierde verbinding wat niks met die VPN te doen het nie.
Lees die eindpunt wat die GUI werklik gebruik
Maak die verbinding se eienskappe oop en kopieer vier waardes: gasheer, poort, databasis en rol. Soek dan na 'n tonnel-oortjie, want 'n SSH-deurvoer verander 'n private adres in 'n plaaslike poort en verander wat aan psql gesê moet word.
| 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 |
Elke ry misluk op 'n ander laag, en die boodskap wat jy kry, noem daardie laag. Om die vriendelike naam van die gestoorde profiel in psql te plak, dra niks van die waardes hierbo nie, en 'n diensnaam los op deur 'n lêer wat die terminale dalk nooit lees nie.
Wat libpq van jou dop erf
psql is 'n dun kliënt bo libpq, en libpq lees die omgewing voordat hy enigiets anders lees. Veranderlikes soos PGHOST, PGHOSTADDR, PGPORT, PGDATABASE, PGUSER, PGSERVICE en PGSSLMODE kan elk 'n deel van die verbinding herlei. Hulle word geërf eerder as getik, so niks in die opdrag wat jy uitgevoer het, wys hulle nie. 'n Uitgevoerde PGSSLMODE kan ook verander wat die kliënt aanvaar, sonder 'n woord op die opdraglyn.
Twee van daardie veranderlikes verdien eerste agterdog. PGHOSTADDR verskaf 'n numeriese bestemming wat naamresolusie oorheers terwyl die gasheernaam steeds sertifikaatidentiteit bepaal, en PGSERVICE trek gasheer, databasis en TLS-keuses uit 'n dienslêer. Om die hele omgewing te stort om dit te ontfout, is 'n slegte gewoonte, want dit kan wagwoorde en onverwante tekens bevat; kies eerder die veranderlikes wat vir jou saak maak.
Om beide host en hostaddr weg te laat, kies 'n Unix-domeinsokkel eerder as 'n netwerkadres. 'n psql-aanroep sonder -h kan dus plaaslik slaag, of met 'n sokfout misluk, sonder om ooit die roete te raak wat die GUI gebruik.
Stuur dieselfde parameters met die hand
Met die GUI se waardes in die hand, gee hulle eksplisiet deur en slaan die opstartlêer oor wat oorheersings kan byvoeg. Die verbindingstring hieronder is illustratief: vervang die eindpunt, poort, databasis en rol met die waardes wat jou administrateur goedgekeur het, en hou die vertroukonfigurasie wat reeds werk.
psql -X "host=db.internal.example port=6432 dbname=orders user=report_ro sslmode=verify-full connect_timeout=5"Drie besonderhede in daardie opdrag is doelbewus. -X onderdruk psql se opstartlêer, hoewel dit nie libpq se omgewing of 'n diensdefinisie onderdruk nie. connect_timeout=5 keer dat 'n swartgat-roete die terminale vir minute laat hang. sslmode=verify-full hou sertifikaat- en gasheernaamkontroles aangeskakel, wat presies die deel is wat mense afskakel wanneer 'n TLS-fout verskyn.
As die goedgekeurde eindpunt agter 'n pooler sit, kan poort 6432 en poort 5432 dieselfde data deur verskillende bedieneridentiteite bereik, en verifikasie kan op die pooler se naam misluk eerder as op die databasis se naam. Korrigeer die naam in die verbindingstring in plaas daarvan om die modus te verswak.
Laat die foutboodskap die volgende stap kies
Die mislukkingsteks sê hoe ver die poging gekom het, wat enige raaiskoot oor die tonnel klop. 'n Naam wat nie sal oplos nie, misluk voordat 'n sokkel bestaan, 'n tydsverloop beteken die roete of 'n vuurmuur het pakkette laat val, 'n weiering beteken iets het geantwoord en geweier, en 'n outentiseringsfout beteken die netwerk het reeds gewerk.
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 --versionVergelyk die \conninfo-uitset met die GUI se lewendige sessie: dieselfde gasheer, dieselfde poort, dieselfde rol, dieselfde TLS-toestand. Wanneer daardie vier saamstem, het die VPN niks meer om te verduidelik nie. Totdat hulle saamstem, is elke ekstra tonnelverandering 'n raaiskoot oor 'n verbinding wat die terminale nooit gemaak het.