La VPN no bloqueja psql: el vostre client marca una altra destinació
psql i un client GUI poden marcar extrems diferents des d'una mateixa màquina. Compareu amfitrió, sòcol, rol i TLS abans de culpar la VPN.
Els dos clients són al mateix portàtil, travessen el mateix túnel i només un d’ells es connecta. Aquesta comparació sembla una prova que la VPN és selectiva, quan l’explicació molt més habitual és que els dos clients marquen destinacions diferents. Una GUI conserva el seu propi amfitrió, port, rol i paràmetres TLS i construeix silenciosament un reenviament SSH quan en necessita un, mentre que psql munta una connexió a partir dels valors per defecte de libpq que la vostra shell pot haver establert ja. Reproduir la connexió que funciona és qüestió de llegir els paràmetres de la GUI, no de reinstal·lar el túnel.
El mite: un client que funciona demostra el camí
Si la GUI es connecta, el túnel transporta trànsit, i això és l’únic que demostra la GUI. No diu res sobre quina adreça resol psql, amb quin rol s’autentica o si el sòcol que obre arriba a sortir mai de la màquina. El camí és compartit; els paràmetres no.
Un reenviament local eixampla la diferència. La GUI es pot connectar a 127.0.0.1 en un port que ha reenviat per SSH, i aquest oient només existeix mentre dura la sessió de la GUI. psql apuntat a localhost sense el reenviament rep una connexió rebutjada que no té res a veure amb la VPN.
Llegeix l’extrem que la GUI fa servir realment
Obriu les propietats de la connexió i copieu quatre valors: amfitrió, port, base de dades i rol. Després busqueu una pestanya de túnel, perquè un reenviament SSH converteix una adreça privada en un port local i canvia què cal dir a 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 |
Cada fila falla en una capa diferent, i el missatge que rebeu anomena aquesta capa. Enganxar el nom amigable del perfil desat a psql no porta cap dels valors anteriors, i un nom de servei es resol mitjançant un fitxer que el terminal potser no llegirà mai.
Què hereta libpq de la vostra shell
psql és un client prim sobre libpq, i libpq llegeix l’entorn abans de llegir qualsevol altra cosa. Variables com PGHOST, PGHOSTADDR, PGPORT, PGDATABASE, PGUSER, PGSERVICE i PGSSLMODE poden redirigir cadascuna una part de la connexió. S’hereten en lloc d’escriure’s, així que res de l’ordre que heu executat no les mostra. Una PGSSLMODE exportada també pot canviar què accepta el client sense dir ni una paraula a la línia d’ordres.
Dues d’aquestes variables mereixen sospita primer. PGHOSTADDR proporciona una destinació numèrica que substitueix la resolució de noms mentre el nom d’amfitrió encara regeix la identitat del certificat, i PGSERVICE treu l’amfitrió, la base de dades i les opcions de TLS d’un fitxer de servei. Bolcar tot l’entorn per depurar-ho és un mal hàbit, ja que pot contenir contrasenyes i testimonis no relacionats; seleccioneu les variables que us interessen.
Ometre tant host com hostaddr selecciona un sòcol de domini Unix en lloc d’una adreça de xarxa. Una crida psql sense -h pot, per tant, tenir èxit localment o fallar amb un error de sòcol, sense tocar mai la ruta que fa servir la GUI.
Envieu els mateixos paràmetres a mà
Amb els valors de la GUI a la mà, passeu-los explícitament i salteu el fitxer d’inici que podria afegir substitucions. La cadena de connexió de sota és il·lustrativa: substituïu l’extrem, el port, la base de dades i el rol pels valors que el vostre administrador ha aprovat, i manteniu la configuració de confiança que ja funciona.
psql -X "host=db.internal.example port=6432 dbname=orders user=report_ro sslmode=verify-full connect_timeout=5"Tres detalls d’aquesta ordre són deliberats. -X suprimeix el fitxer d’inici de psql, encara que no suprimeix l’entorn de libpq ni una definició de servei. connect_timeout=5 evita que una ruta bloquejada pengi el terminal durant minuts. sslmode=verify-full manté activades les comprovacions de certificat i d’amfitrió, que és exactament la part que la gent desactiva quan apareix un error TLS.
Si l’extrem aprovat és darrere d’un pooler, el port 6432 i el port 5432 poden arribar a les mateixes dades a través d’identitats de servidor diferents, i la verificació pot fallar pel nom del pooler en lloc del de la base de dades. Corregiu el nom a la cadena de connexió en lloc d’afeblir el mode.
Deixeu que el missatge d’error triï el següent pas
El text del fracàs diu fins on ha arribat l’intent, i això supera qualsevol conjectura sobre el túnel. Un nom que no es resol falla abans que existeixi un sòcol, un temps d’espera vol dir que la ruta o un tallafocs ha descartat paquets, un rebuig vol dir que alguna cosa ha respost i ha declinat, i un error d’autenticació vol dir que la xarxa ja funcionava.
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 --versionCompareu la sortida de \conninfo amb la sessió en directe de la GUI: mateix amfitrió, mateix port, mateix rol, mateix estat TLS. Quan aquests quatre coincideixen, la VPN no té res més a explicar. Fins que coincideixin, cada canvi addicional al túnel és una conjectura sobre una connexió que el terminal no ha fet mai.