VPN'en blokerer ikke psql: din klient ringer et andet sted hen
psql og en GUI-klient kan ringe til forskellige endepunkter fra samme maskine. Sammenlign vært, socket, rolle og TLS, før du bebrejder VPN'en.
Begge klienter sidder på den samme bærbare computer, går gennem den samme tunnel, og kun én af dem opretter forbindelse. Den sammenligning føles som bevis på, at VPN'en er selektiv, mens den langt mere almindelige forklaring er, at de to klienter ringer til forskellige destinationer. En GUI holder sin egen vært, port, rolle og TLS-indstillinger og bygger i al stilhed en SSH-videresendelse, når den har brug for en, mens psql sammensætter en forbindelse ud fra libpq-standardværdier, som din shell måske allerede har sat. At genskabe den fungerende forbindelse er et spørgsmål om at læse GUI'ens indstillinger, ikke om at geninstallere tunnelen.
Myten: én fungerende klient beviser ruten
Hvis GUI'en opretter forbindelse, bærer tunnelen trafik, og det er det eneste, GUI'en beviser. Den siger intet om, hvilken adresse psql opløser, hvilken rolle den autentificerer som, eller om den socket, den åbner, nogensinde forlader maskinen. Ruten deles; parametrene gør ikke.
En lokal videresendelse øger forskellen. GUI'en kan oprette forbindelse til 127.0.0.1 på en port, den har videresendt over SSH, og den lytter findes kun, så længe GUI-sessionen varer. psql rettet mod localhost uden videresendelsen får en afvist forbindelse, der intet har med VPN'en at gøre.
Læs det endepunkt, GUI'en faktisk bruger
Åbn forbindelsens egenskaber, og kopiér fire værdier: vært, port, database og rolle. Se derefter efter en tunnel-fane, fordi en SSH-videresendelse omdanner en privat adresse til en lokal port og ændrer, hvad psql skal fortælles.
| 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 række fejler i et forskelligt lag, og den meddelelse, du får, navngiver det lag. At indsætte det venlige navn på den gemte profil i psql bærer ingen af værdierne ovenfor, og et tjenestenavn opløses gennem en fil, som terminalen måske aldrig læser.
Hvad libpq arver fra din shell
psql er en tynd klient oven på libpq, og libpq læser miljøet, før den læser noget andet. Variabler som PGHOST, PGHOSTADDR, PGPORT, PGDATABASE, PGUSER, PGSERVICE og PGSSLMODE kan hver omdirigere en del af forbindelsen. De arves i stedet for at blive skrevet, så intet i den kommando, du kørte, viser dem. En eksporteret PGSSLMODE kan også ændre, hvad klienten accepterer, uden et ord på kommandolinjen.
To af disse variabler fortjener mistanke først. PGHOSTADDR leverer en numerisk destination, der tilsidesætter navneopløsning, mens værtsnavnet stadig styrer certifikatets identitet, og PGSERVICE trækker vært, database og TLS-valg ud af en tjenestefil. At dumpe hele miljøet for at fejlfinde dette er en dårlig vane, da det kan indeholde adgangskoder og urelaterede tokens; vælg i stedet de variabler, du bryder dig om.
Udeladelse af både host og hostaddr vælger en Unix-domæne-socket i stedet for en netværksadresse. Et psql-kald uden -h kan derfor lykkes lokalt eller fejle med en socket-fejl, uden nogensinde at røre den rute, GUI'en bruger.
Send de samme parametre i hånden
Med GUI'ens værdier ved hånden, send dem eksplicit, og spring den opstartsfil over, der kunne tilføje tilsidesættelser. Forbindelsesstrengen nedenfor er illustrativ: erstat endepunktet, porten, databasen og rollen med de værdier, din administrator har godkendt, og behold den tillidskonfiguration, der allerede virker.
psql -X "host=db.internal.example port=6432 dbname=orders user=report_ro sslmode=verify-full connect_timeout=5"Tre detaljer i den kommando er bevidste. -X undertrykker psql's opstartsfil, selv om den ikke undertrykker libpq's miljø eller en tjenestedefinition. connect_timeout=5 forhindrer, at en sort-hul-rute får terminalen til at hænge i minutter. sslmode=verify-full holder certifikat- og værtsnavnekontroller slået til, hvilket netop er den del, folk slår fra, når en TLS-fejl vises.
Hvis det godkendte endepunkt ligger bag en pooler, kan port 6432 og port 5432 nå de samme data gennem forskellige serveridentiteter, og verifikationen kan fejle på poolerens navn i stedet for databasens. Ret navnet i forbindelsesstrengen i stedet for at svække tilstanden.
Lad fejlmeddelelsen vælge næste skridt
Fejlteksten siger, hvor langt forsøget nåede, og det slår ethvert gæt om tunnelen. Et navn, der ikke kan opløses, fejler, før der findes en socket, en timeout betyder, at ruten eller en firewall har droppet pakker, en afvisning betyder, at noget svarede og afslog, og en godkendelsesfejl betyder, at netværket allerede virkede.
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 \conninfo-outputtet med GUI'ens aktive session: samme vært, samme port, samme rolle, samme TLS-tilstand. Når de fire stemmer overens, har VPN'en intet tilbage at forklare. Indtil de stemmer overens, er enhver ekstra tunnelændring et gæt på en forbindelse, som terminalen aldrig har oprettet.