Terowong naik, QGIS menyambung, dan log masuk mati dengan ralat sijil yang menamakan 127.0.0.1 dan bukannya hos pangkalan data. Langkah seterusnya yang menggoda ialah melonggarkan sslmode, yang mendiamkan pemeriksaan dan membuang jaminan identiti yang anda mahukan sejak awal. Masalah sebenar ialah port setempat dan nama pelayan disimpan dalam medan yang sama. Entri perkhidmatan libpq memisahkannya, jadi soket pergi ke port yang dimajukan manakala TLS masih mengesahkan nama yang tercetak pada sijil.

Apa yang klien fikir ia sambung

Di bawah sslmode=verify-full, libpq membandingkan sijil yang dikemukakan pelayan dengan nama hos yang diminta. Apabila nama itu alamat loopback, perbandingan gagal walaupun sijil sah untuk hos pangkalan data sebenar. Pemajuan SSH menukar soket mana yang membawa bait, bukan identiti yang patut dijangkakan klien. Sebaik sahaja kedua-dua idea itu dipisahkan, ralat tidak lagi kelihatan seperti kerosakan TLS.

Pemajuan juga bukan kebenaran. PostgreSQL masih menggunakan peraturannya sendiri pada sambungan yang dibuat oleh pelayan SSH, jadi asingkan lapisan pengangkutan dan lapisan pangkalan data sebelum mengubah apa-apa.

Ikat pemajuan hanya pada loopback

Pendengar harus wujud pada mesin QGIS dan tidak di tempat lain. Menyebut 127.0.0.1 secara jelas menjauhkannya daripada antara muka lain, manakala alamat ikat yang ditinggalkan boleh mendedahkan port ke luar bergantung pada tetapan gerbang klien SSH.

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

Destinasi selepas titik bertindih kedua diselesaikan dari sisi pelayan SSH, jadi contoh ini menganggap PostgreSQL berada pada hos yang sama dengan sshd; pangkalan data pada mesin lain memerlukan alamat itu dan kebenarannya. Jalankan sesi dengan -N supaya tiada cangkerang dibuka, biarkan pengesahan kunci hos, dan pastikan pendengar muncul sebelum menyalahkan QGIS. Jika port sudah digunakan, pemajuan gagal semasa permulaan dan bukan semasa pertanyaan.

Letakkan nama dan soket dalam satu entri perkhidmatan

Fail perkhidmatan membolehkan sambungan yang sama membawa nama pengesahan dan destinasi soket yang berbeza. Simpan entri di tempat libpq mencari perkhidmatan, atau halakan PGSERVICEFILE ke arahnya.

[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

Di sini host mengekalkan identiti yang digunakan untuk pemeriksaan sijil manakala hostaddr menghantar paket ke port loopback yang dimajukan, dan kedua-duanya diperlukan untuk susunan ini berfungsi. gssencmode=disable penting pada binaan yang jika tidak akan merundingkan penyulitan GSSAPI dahulu, kerana laluan itu mengabaikan tetapan TLS yang baru ditetapkan. Rujuk perkhidmatan itu dengan nama dari dialog sambungan PostgreSQL QGIS dan berikan kata laluan melalui gesaan biasa, bukan di dalam fail yang dikongsi. Nama dan laluan di atas ialah pemegang tempat; gantikannya dengan nilai anda sendiri yang diluluskan.

Apa yang PostgreSQL masih periksa selepas terowong

Pelayan melihat sambungan dari hos SSH, loopback dalam susunan ini, dan memadankannya mengikut urutan dengan peraturan pengesahan berasaskan hos. Peranan pangkalan data anda masih perlu disahkan, dan log masuk SSH tidak memberikan identiti pangkalan data dengan sendirinya. Sahkan apa yang pelayan percaya, bukan apa yang klien andaikan.

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

Tutup sesi pemajuan apabila kerja selesai; entri setempat kemudian berhenti berfungsi dan tiada apa lagi yang berubah. Satu laluan pangkalan data bukan VPN untuk keseluruhan klien GIS, dan memperlakukannya sebagai VPN itulah yang menyebabkan sambungan seterusnya salah didiagnosis.

Artikel berkaitan