A VPN non bloquea psql: o teu cliente marca outro destino
psql e un cliente GUI poden marcar extremos distintos desde unha mesma máquina. Compara host, socket, rol e TLS antes de culpar a VPN.
Os dous clientes están no mesmo portátil, atravesan o mesmo túnel e só un deles se conecta. Ese comparación parece unha proba de que a VPN é selectiva, cando a explicación moito máis habitual é que os dous clientes marcan destinos distintos. Unha GUI garda o seu propio host, porto, rol e axustes de TLS e constrúe en silencio un reenvío SSH cando o necesita, mentres que psql arma unha conexión a partir dos valores predeterminados de libpq que a túa shell quizais xa estableceu. Reproducir a conexión que funciona é cuestión de ler os axustes da GUI, non de reinstalar o túnel.
O mito: un cliente que funciona demostra a ruta
Se a GUI se conecta, o túnel transporta tráfico, e iso é o único que demostra a GUI. Non di nada sobre que enderezo resolve psql, con que rol se autentica nin se o socket que abre chega a saír da máquina. A ruta é compartida; os parámetros non.
Un reenvío local amplía a diferenza. A GUI pode conectarse a 127.0.0.1 nun porto que reenviou por SSH, e ese receptor só existe mentres dura a sesión da GUI. psql apuntado a localhost sen o reenvío recibe unha conexión rexeitada que non ten nada que ver coa VPN.
Le o extremo que a GUI usa de verdade
Abre as propiedades da conexión e copia catro valores: host, porto, base de datos e rol. Despois busca unha pestana de túnel, porque un reenvío SSH converte un enderezo privado nun porto local e cambia o que hai que dicirlle 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 nunha capa distinta, e a mensaxe que recibes nomea esa capa. Pegar o nome amigable do perfil gardado en psql non achega ningún dos valores anteriores, e un nome de servizo resólvese mediante un ficheiro que o terminal quizais nunca lea.
Que herda libpq da túa shell
psql é un cliente lixeiro sobre libpq, e libpq le o contorno antes de ler calquera outra cousa. Variables como PGHOST, PGHOSTADDR, PGPORT, PGDATABASE, PGUSER, PGSERVICE e PGSSLMODE poden redirixir cada unha parte da conexión. Herdanse en lugar de escribirse, así que nada no comando que executaches as mostra. Unha PGSSLMODE exportada tamén pode cambiar o que acepta o cliente sen unha palabra na liña de comandos.
Dúas desas variables merecen sospeita primeiro. PGHOSTADDR achega un destino numérico que anula a resolución de nomes mentres o nome de host segue rexendo a identidade do certificado, e PGSERVICE saca host, base de datos e opcións de TLS dun ficheiro de servizo. Volcar todo o contorno para depurar isto é un mal hábito, xa que pode conter contrasinais e tokens non relacionados; selecciona mellor as variables que che importan.
Omitir tanto host como hostaddr selecciona un socket de dominio Unix en lugar dun enderezo de rede. Unha chamada a psql sen -h pode, por tanto, ter éxito localmente ou fallar cun erro de socket, sen tocar nunca a ruta que usa a GUI.
Envía os mesmos parámetros a man
Cos valores da GUI na man, pásalos explicitamente e salta o ficheiro de inicio que podería engadir anulacións. A cadea de conexión de abaixo é ilustrativa: substitúe o extremo, o porto, a base de datos e o rol polos valores que aprobou o teu administrador, e conserva a configuración de confianza que xa funciona.
psql -X "host=db.internal.example port=6432 dbname=orders user=report_ro sslmode=verify-full connect_timeout=5"Tres detalles dese comando son deliberados. -X suprime o ficheiro de inicio de psql, aínda que non suprime o contorno de libpq nin unha definición de servizo. connect_timeout=5 evita que unha ruta bloqueada colgue o terminal durante minutos. sslmode=verify-full mantén activadas as comprobacións de certificado e de nome de host, que é xusto a parte que a xente desactiva cando aparece un erro de TLS.
Se o extremo aprobado está detrás dun pooler, o porto 6432 e o porto 5432 poden chegar aos mesmos datos mediante identidades de servidor distintas, e a verificación pode fallar polo nome do pooler en lugar do da base de datos. Corrixe o nome na cadea de conexión en vez de debilitar o modo.
Deixa que a mensaxe de erro escolla o seguinte paso
O texto do fallo di ata onde chegou o intento, e iso supera calquera conxectura sobre o túnel. Un nome que non se resolve falla antes de que exista un socket, un tempo de espera significa que a ruta ou un devasado descartou paquetes, un rexeitamento significa que algo respondeu e negouse, e un erro de autenticación significa que a rede xa funcionaba.
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 --versionCompara a saída de \conninfo coa sesión en vivo da GUI: mesmo host, mesmo porto, mesmo rol, mesmo estado de TLS. Cando eses catro coinciden, a VPN non ten nada máis que explicar. Ata que coincidan, cada cambio adicional no túnel é unha conxectura sobre unha conexión que o terminal nunca fixo.