Tunela altxatzen da, QGIS konektatzen da, eta saioa hasteak huts egiten du datu-basearen ostalariaren ordez 127.0.0.1 aipatzen duen ziurtagiri-errore batekin. Hurrengo urrats tentagarria sslmode lasaitzea da, eta horrek egiaztapena isilarazten du eta hasieran nahi zenuen identitate-bermea botatzen du. Benetako arazoa da portu lokala eta zerbitzariaren izena eremu berean gordetzen direla. libpq zerbitzu-sarrera batek bereizten ditu, beraz socket-a birbideratutako portura doa, TLS oraindik ziurtagirian inprimatutako izena egiaztatzen duen bitartean.

Zerera konektatzen ari dela uste du bezeroak

sslmode=verify-full moduan, libpq-k zerbitzariak aurkezten duen ziurtagiria eskatutako ostalari-izenarekin alderatzen du. Izen hori loopback helbidea denean, alderaketak huts egiten du ziurtagiria benetako datu-basearen ostalariarentzat baliozkoa izan arren. SSH birbidalketak aldatzen du zein socket-ek daraman bytea, ez bezeroak espero beharko lukeen identitatea. Bi ideia horiek bereizita, erroreak ez du TLS akats itxurarik egiten.

Birbidalketa ez da baimenik ere. PostgreSQLek oraindik bere arauak aplikatzen dizkio SSH zerbitzariak egiten duen konexioari, beraz edozer aldatu aurretik mantendu garraio-geruza eta datu-basearen geruza bereizita.

Lotu birbidalketa loopback-era soilik

Entzulea QGIS makinan egon behar du eta inon ez beste inon. 127.0.0.1 esplizituki aipatzeak beste interfazeetatik kanpo uzten du, eta baztertutako lotura-helbideak portua kanpora ireki dezake SSH bezeroaren atebide-ezarpenen arabera.

ssh -N -L 127.0.0.1:15432:127.0.0.1:5432 [email protected]

Bigarren bi puntuen ondorengo helburua SSH zerbitzariaren aldean ebazten da, beraz adibide honek PostgreSQL sshd dagoen ostalari berean dagoela suposatzen du; beste makina bateko datu-base batek helbide hori eta haren baimenak behar ditu. Abiarazi saioa -N aukerarekin shell-ik ireki ez dadin, utzi ostalari-gakoaren egiaztapena bakean, eta egiaztatu entzulea agertzen dela QGIS erruduntzat jo aurretik. Portua jada erabilita badago, birbidalketak abiaraztean huts egiten du, ez kontsulta egitean.

Jarri izena eta socket-a zerbitzu-sarrera bakarrean

Zerbitzu-fitxategi batek konexio berari egiaztapen-izen bat eta socket helburu desberdin bat eramatea ahalbidetzen du. Gorde sarrera libpq-k zerbitzuak bilatzen dituen tokian, edo zuzendu PGSERVICEFILE hara.

[gis-via-ssh]
host=db.geo.example
hostaddr=127.0.0.1
port=15432
dbname=gisdb
user=gis_reader
sslmode=verify-full
gssencmode=disable
sslrootcert=/path/to/approved-root.crt

Hemen host ziurtagiri-egiaztapenetarako erabiltzen den identitatea gordetzen du, eta hostaddr paketeak birbideratutako loopback portura bidaltzen ditu; biak beharrezkoak dira antolamendu honek lan egin dezan. gssencmode=disable garrantzitsua da bestela lehenengo GSSAPI zifratzea negoziatuko luketen build-etan, bide horrek une horretan ezarritako TLS ezarpenak alde batera uzten baititu. Aipatu zerbitzua izenez QGISen PostgreSQL konexio-elkarrizketatik, eta eman pasahitza ohiko galdetegiaren bidez, ez partekatutako fitxategi baten barruan. Goiko izenak eta bideak leku-markak dira; ordeztu zure balio onartuekin.

Zer egiaztatzen duen PostgreSQLek tunelaren ondoren

Zerbitzariak SSH ostalaritik datorren konexioa ikusten du, antolamendu honetan loopback, eta ostalariaren araberako autentifikazio-arauetara egokitzen du hurrenez hurren. Zure datu-basearen rolek oraindik autentifikatu behar du, eta SSH saio-hasierak ez du datu-basearen identitaterik ematen berez. Egiaztatu zerbitzariak zer uste duen, bezeroak zer suposatu zuen eta ez.

psql "service=gis-via-ssh" -c "select inet_server_addr(), current_user"

Itxi birbidalketa-saioa lana amaitu denean; sarrera lokalak orduan funtzionatzeari uzten dio eta beste ezerk ez du aldatzen. Datu-baserako bide bat ez da VPN bat GIS bezero osoarentzat, eta halakotzat hartzea da hurrengo konexioa gaizki diagnostikatzearen arrazoia.

Erlazionatutako artikuluak