La VPN ne blokas psql: via kliento alvokas aliloke

Ambaŭ klientoj sidas sur la sama portebla komputilo, trapasas la saman tunelon, kaj nur unu el ili konektiĝas. Tiu komparo sentiĝas kiel pruvo, ke la VPN estas elektema, dum la multe pli ofta klarigo estas, ke la du klientoj alvokas malsamajn celojn. GUI tenas sian propran gastiganton, pordon, rolon kaj TLS-agordojn kaj silente konstruas SSH-plusendadon kiam ĝi bezonas unu, dum psql kunmetas konekton el libpq-defaŭltoj, kiujn via ŝelo eble jam agordis. Reprodukti la funkciantan konekton temas pri legi la agordojn de la GUI, ne pri reinstali la tunelon.

La mito: unu funkcianta kliento pruvas la vojon

Se la GUI konektiĝas, la tunelo portas trafikon, kaj tio estas la sola afero, kiun la GUI pruvas. Ĝi diras nenion pri tio, kiun adreson psql solvas, per kiu rolo ĝi aŭtentikigas, aŭ ĉu la ingo, kiun ĝi malfermas, iam forlasas la maŝinon. La vojo estas komuna; la parametroj ne.

Loka plusendado pligrandigas la diferencon. La GUI povas konektiĝi al 127.0.0.1 sur pordo, kiun ĝi plusendis tra SSH, kaj tiu aŭskultanto ekzistas nur dum la GUI-sesio. psql direktita al localhost sen la plusendado ricevas rifuzitan konekton, kiu havas nenion komunan kun la VPN.

Legu la celon, kiun la GUI fakte uzas

Malfermu la ecojn de la konekto kaj kopiu kvar valorojn: gastiganto, pordo, datumbazo kaj rolo. Poste serĉu langeton pri tunelo, ĉar SSH-plusendado transformas privatan adreson en lokan pordon kaj ŝanĝas tion, kion oni devas diri al psql.

Ĉiu vico malsukcesas en malsama tavolo, kaj la mesaĝo, kiun vi ricevas, nomas tiun tavolon. Alglui la amikan nomon de la konservita profilo en psql portas neniun el la supraj valoroj, kaj serva nomo solviĝas per dosiero, kiun la terminalo eble neniam legos.

Kion libpq heredas de via ŝelo

psql estas maldika kliento super libpq, kaj libpq legas la medion antaŭ ol legi ion ajn alian. Variabloj kiel PGHOST, PGHOSTADDR, PGPORT, PGDATABASE, PGUSER, PGSERVICE kaj PGSSLMODE povas ĉiu alidirekti parton de la konekto. Ili estas heredataj anstataŭ tajpataj, do nenio en la komando, kiun vi rulis, montras ilin. Elportita PGSSLMODE ankaŭ povas ŝanĝi tion, kion la kliento akceptas sen unu vorto sur la komandlinio.

Du el tiuj variabloj unue meritas suspekton. PGHOSTADDR liveras nombran celon, kiu superregas nomosolvadon dum la gastigantnomo ankoraŭ regas la identecon de la atestilo, kaj PGSERVICE eltiras gastiganton, datumbazon kaj TLS-elektojn el serva dosiero. Elverŝi la tutan medion por elpurigi tion estas malbona kutimo, ĉar ĝi povas enhavi pasvortojn kaj nerilatajn ĵetonojn; anstataŭe elektu la variablojn, kiuj gravas al vi.

Forlasi kaj host kaj hostaddr elektas ingon de Unix-domajno anstataŭ retadreson. psql-voko sen -h povas do sukcesi loke, aŭ malsukcesi per inga eraro, sen eĉ tuŝi la vojon, kiun la GUI uzas.

Sendu la samajn parametrojn permane

Kun la valoroj de la GUI en la mano, transdonu ilin eksplice kaj saltu la startan dosieron, kiu povus aldoni superregadojn. La konekta ĉeno sube estas ilustra: anstataŭigu la celon, pordon, datumbazon kaj rolon per la valoroj, kiujn aprobis via administranto, kaj konservu la fidan agordon, kiu jam funkcias.

psql -X "host=db.internal.example port=6432 dbname=orders user=report_ro sslmode=verify-full connect_timeout=5"

Tri detaloj en tiu komando estas intencaj. -X subpremas la startan dosieron de psql, kvankam ĝi ne subpremas la medion de libpq aŭ servan difinon. connect_timeout=5 malhelpas, ke vojo en malplenon pendigu la terminalon dum minutoj. sslmode=verify-full tenas la kontrolojn de atestilo kaj gastigantnomo ŝaltitaj, kio estas precize la parto, kiun homoj malŝaltas kiam aperas TLS-eraro.

Se la aprobita celo staras malantaŭ pooler, pordo 6432 kaj pordo 5432 povas atingi la samajn datumojn per malsamaj servilaj identecoj, kaj la kontrolo povas malsukcesi je la nomo de la pooler anstataŭ tiu de la datumbazo. Korektu la nomon en la konekta ĉeno anstataŭ malfortigi la reĝimon.

Lasu la erarmesaĝon elekti la sekvan paŝon

La malsukcesa teksto diras, kiom malproksimen iris la provo, kaj tio venkas ĉiun konjekton pri la tunelo. Nomo, kiu ne solviĝos, malsukcesas antaŭ ol ingo ekzistas, tempolimo signifas, ke la vojo aŭ fajromuro faligis pakojn, rifuzo signifas, ke io respondis kaj rifuzis, kaj aŭtentiga eraro signifas, ke la reto jam funkciis.

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 --version

Komparu la eligon de \conninfo kun la viva sesio de la GUI: sama gastiganto, sama pordo, sama rolo, sama TLS-stato. Kiam tiuj kvar konsentas, la VPN havas nenion plu klarigendan. Ĝis ili konsentos, ĉiu plia tunela ŝanĝo estas konjekto pri konekto, kiun la terminalo neniam faris.