VPN-en blokkerer ikke psql: klienten din går et annet sted
psql og en GUI-klient kan gå til ulike endepunkter fra samme maskin. Sammenlign vert, sokkel, rolle og TLS før du klandrer VPN-en.
Begge klientene sitter på samme bærbare datamaskin, går gjennom samme tunnel, og bare én av dem kobler til. Sammenligningen føles som bevis på at VPN-en er selektiv, mens den langt vanligere forklaringen er at de to klientene går til ulike destinasjoner. En GUI holder sin egen vert, port, rolle og TLS-innstillinger og bygger stille en SSH-videresending når den trenger det, mens psql setter sammen en tilkobling fra libpq-standardverdier som skallet ditt kanskje allerede har satt. Å gjenskape den fungerende tilkoblingen er et spørsmål om å lese GUI-ens innstillinger, ikke om å installere tunnelen på nytt.
Myten: én fungerende klient beviser veien
Hvis GUI-en kobler til, frakter tunnelen trafikk, og det er det eneste GUI-en beviser. Den sier ingenting om hvilken adresse psql slår opp, hvilken rolle den autentiserer som, eller om sokkelen den åpner noen gang forlater maskinen. Veien deles; parameterne gjør det ikke.
En lokal videresending øker forskjellen. GUI-en kan koble til 127.0.0.1 på en port den har videresendt over SSH, og den lytteren finnes bare så lenge GUI-økten varer. psql rettet mot localhost uten videresendingen får en avvist tilkobling som ikke har noe med VPN-en å gjøre.
Les endepunktet GUI-en faktisk bruker
Åpne egenskapene til tilkoblingen og kopier fire verdier: vert, port, database og rolle. Se deretter etter en tunnel-fane, fordi en SSH-videresending gjør en privat adresse om til en lokal port og endrer hva psql må få beskjed om.
| 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 |
Hver rad feiler i et ulikt lag, og meldingen du får navngir det laget. Å lime inn det vennlige navnet til den lagrede profilen i psql bærer ingen av verdiene ovenfor, og et tjenestenavn slås opp gjennom en fil terminalen kanskje aldri leser.
Hva libpq arver fra skallet ditt
psql er en tynn klient over libpq, og libpq leser miljøet før den leser noe annet. Variabler som PGHOST, PGHOSTADDR, PGPORT, PGDATABASE, PGUSER, PGSERVICE og PGSSLMODE kan hver omdirigere en del av tilkoblingen. De arves i stedet for å skrives, så ingenting i kommandoen du kjørte viser dem. En eksportert PGSSLMODE kan også endre hva klienten godtar uten et ord på kommandolinjen.
To av disse variablene fortjener mistanke først. PGHOSTADDR leverer en numerisk destinasjon som overstyrer navneoppslag mens vertsnavnet fortsatt styrer sertifikatets identitet, og PGSERVICE trekker vert, database og TLS-valg ut av en tjenestefil. Å dumpe hele miljøet for å feilsøke dette er en dårlig vane, siden det kan inneholde passord og urelaterte tokens; velg i stedet variablene du bryr deg om.
Å utelate både host og hostaddr velger en Unix-domenesokkel i stedet for en nettverksadresse. Et psql-kall uten -h kan derfor lykkes lokalt, eller feile med en sokkel-feil, uten å noen gang berøre ruten GUI-en bruker.
Send de samme parameterne for hånd
Med GUI-ens verdier i hånden, send dem eksplisitt og hopp over oppstartsfilen som kan legge til overstyringer. Tilkoblingsstrengen nedenfor er illustrativ: bytt ut endepunktet, porten, databasen og rollen med verdiene administratoren din har godkjent, og behold tillitskonfigurasjonen som allerede fungerer.
psql -X "host=db.internal.example port=6432 dbname=orders user=report_ro sslmode=verify-full connect_timeout=5"Tre detaljer i den kommandoen er bevisste. -X undertrykker psqls oppstartsfil, selv om den ikke undertrykker libpq-miljøet eller en tjenestedefinisjon. connect_timeout=5 hindrer at en svart-hull-rute får terminalen til å henge i minutter. sslmode=verify-full holder sertifikat- og vertsnavnkontroller slått på, som er nettopp den delen folk slår av når en TLS-feil dukker opp.
Hvis det godkjente endepunktet ligger bak en pooler, kan port 6432 og port 5432 nå de samme dataene gjennom ulike serveridentiteter, og verifiseringen kan feile på poolerens navn i stedet for databasens. Rett navnet i tilkoblingsstrengen i stedet for å svekke modusen.
La feilmeldingen velge neste steg
Feilteksten sier hvor langt forsøket kom, og det slår enhver gjetning om tunnelen. Et navn som ikke slås opp, feiler før en sokkel finnes, et tidsavbrudd betyr at ruten eller en brannmur slapp pakkene, en avvisning betyr at noe svarte og avslo, og en autentiseringsfeil betyr at nettverket allerede virket.
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 --versionSammenlign utdataene fra \conninfo med GUI-ens aktive økt: samme vert, samme port, samme rolle, samme TLS-tilstand. Når de fire stemmer, har VPN-en ingenting mer å forklare. Inntil de stemmer, er enhver ekstra tunnelendring en gjetning om en tilkobling terminalen aldri har laget.