VPN neužblokuoja psql: jūsų klientas kreipiasi kitur
psql ir GUI klientas gali iš vieno kompiuterio kreiptis į skirtingus galinius taškus. Prieš kaltindami VPN, palyginkite hostą, socket, vaidmenį ir TLS.
Abu klientai yra tame pačiame nešiojamajame kompiuteryje, eina per tą patį tunelį, ir tik vienas iš jų prisijungia. Šis palyginimas atrodo kaip įrodymas, kad VPN yra selektyvus, nors kur kas dažnesnis paaiškinimas yra tai, kad du klientai kreipiasi į skirtingus tikslus. GUI laiko savo host, portą, vaidmenį ir TLS nustatymus ir tyliai sukuria SSH persiuntimą, kai jo reikia, o psql surenka ryšį iš libpq numatytųjų reikšmių, kurias jūsų shell galėjo jau nustatyti. Veikiančio ryšio atkūrimas yra GUI nustatymų skaitymas, o ne tunelio persiuntimas iš naujo.
Mitas: vienas veikiantis klientas įrodo kelią
Jei GUI prisijungia, tunelis perduoda srautą, ir tai yra vienintelis dalykas, kurį GUI įrodo. Jis nieko nesako apie tai, kurį adresą psql išsprendžia, kokiu vaidmeniu autentifikuojasi, ar jo atidaromas socket kada nors palieka kompiuterį. Kelias yra bendras; parametrai – ne.
Vietinis persiuntimas padidina skirtumą. GUI gali prisijungti prie 127.0.0.1 prievado, kurį persiuntė per SSH, ir tas klausytojas egzistuoja tik GUI sesijos metu. psql, nukreiptas į localhost be persiuntimo, gauna atmestą ryšį, kuris neturi nieko bendra su VPN.
Perskaitykite galinį tašką, kurį GUI iš tikrųjų naudoja
Atidarykite ryšio ypatybes ir nukopijuokite keturias reikšmes: host, portą, duomenų bazę ir vaidmenį. Tada ieškokite tunelio skirtuko, nes SSH persiuntimas privačią adresą paverčia vietiniu prievadu ir pakeičia tai, ką reikia pasakyti 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 |
Kiekviena eilutė nepavyksta skirtingame sluoksnyje, o gauta žinutė įvardija tą sluoksnį. Įklijavus į psql išsaugoto profilio draugišką pavadinimą, nė viena iš aukščiau nurodytų reikšmių neperduodama, o paslaugos pavadinimas išsprendžiamas per failą, kurio terminalas gali niekada nepaskaityti.
Ką libpq paveldi iš jūsų shell
psql yra plonas klientas virš libpq, o libpq aplinką skaito prieš viską kita. Tokie kintamieji kaip PGHOST, PGHOSTADDR, PGPORT, PGDATABASE, PGUSER, PGSERVICE ir PGSSLMODE gali kiekvienas nukreipti dalį ryšio. Jie paveldimi, o ne įrašomi, todėl niekas jūsų vykdytoje komandoje jų nerodo. Eksportuotas PGSSLMODE taip pat gali pakeisti, ką klientas priima, be vieno žodžio komandinėje eilutėje.
Du iš tų kintamųjų pirmiausia verti įtarimo. PGHOSTADDR pateikia skaitmeninį tikslą, kuris nepaiso vardų sprendimo, o hosto vardas vis dar lemia sertifikato tapatybę, ir PGSERVICE ištraukia hostą, duomenų bazę bei TLS pasirinkimus iš paslaugos failo. Visos aplinkos išmetimas derinimui yra blogas įprotis, nes joje gali būti slaptažodžių ir nesusijusių žetonų; vietoj to pasirinkite jums svarbius kintamuosius.
Praleidus ir host, ir hostaddr, pasirenkamas Unix domeno socket, o ne tinklo adresas. Todėl psql iškvietimas be -h gali pavykti vietoje arba nepavykti dėl socket klaidos, net nepaliesdamas maršruto, kurį naudoja GUI.
Siųskite tuos pačius parametrus rankiniu būdu
Turėdami GUI reikšmes, perduokite jas aiškiai ir praleiskite paleidimo failą, kuris galėtų pridėti perrašymus. Žemiau pateikta prisijungimo eilutė yra iliustracinė: pakeiskite galinį tašką, prievadą, duomenų bazę ir vaidmenį administratoriaus patvirtintomis reikšmėmis, o jau veikiančią pasitikėjimo konfigūraciją palikite.
psql -X "host=db.internal.example port=6432 dbname=orders user=report_ro sslmode=verify-full connect_timeout=5"Trys šios komandos detalės yra tyčinės. -X slopina psql paleidimo failą, nors neslopina libpq aplinkos ar paslaugos apibrėžties. connect_timeout=5 neleidžia tuščiam maršrutui minutes kabinti terminalo. sslmode=verify-full palieka įjungtus sertifikato ir hosto vardo patikrinimus, o tai yra būtent ta dalis, kurią žmonės išjungia, kai pasirodo TLS klaida.
Jei patvirtintas galinis taškas yra už pooler, 6432 prievadas ir 5432 prievadas gali pasiekti tuos pačius duomenis per skirtingas serverio tapatybes, o tikrinimas gali nepavykti dėl pooler pavadinimo, o ne duomenų bazės. Ištaisykite pavadinimą prisijungimo eilutėje, o ne silpninkite režimą.
Tegul klaidos pranešimas pasirenka kitą žingsnį
Nesėkmės tekstas pasako, kiek toli nuėjo bandymas, ir tai geriau už bet kokį spėjimą apie tunelį. Vardas, kuris neišsprendžiamas, nepavyksta dar prieš atsirandant socket, laiko pasibaigimas reiškia, kad maršrutas ar ugniasienė numetė paketus, atmetimas reiškia, kad kažkas atsakė ir atsisakė, o autentifikavimo klaida reiškia, kad tinklas jau veikė.
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 --versionPalyginkite \conninfo išvestį su gyva GUI sesija: tas pats hostas, tas pats prievadas, tas pats vaidmuo, ta pati TLS būsena. Kai šie keturi sutampa, VPN neturi ko daugiau paaiškinti. Kol jie nesutampa, kiekvienas papildomas tunelio pakeitimas yra spėjimas apie ryšį, kurio terminalas niekada nesukūrė.