QGIS PostGIS SSH tüneli: TLS için sunucu adını koruyun

Bir SSH yönlendirmesi QGIS'e yerel bir bağlantı noktası verir, ancak veritabanının TLS için hâlâ gerçek adına ihtiyacı vardır. hostaddr ve loopback dinleyicisi olan bir libpq hizmeti kullanın.

Tünel açılır, QGIS bağlanır ve oturum açma, veritabanı ana bilgisayarı yerine 127.0.0.1 adını veren bir sertifika hatasıyla ölür. Cazip sonraki adım sslmode ayarını gevşetmektir; bu, denetimi susturur ve başta istediğiniz kimlik garantisini çöpe atar. Asıl sorun, yerel bağlantı noktası ile sunucunun adının aynı alanda saklanmasıdır. Bir libpq hizmet girdisi ikisini ayırır; böylece soket yönlendirilen bağlantı noktasına giderken TLS hâlâ sertifikada basılı adı doğrular.

İstemci neye bağlandığını sanıyor

sslmode=verify-full ayarında libpq, sunucunun sunduğu sertifikayı istenen ana bilgisayar adıyla karşılaştırır. Bu ad bir loopback adresi olduğunda, sertifika gerçek veritabanı ana bilgisayarı için geçerli olsa bile karşılaştırma başarısız olur. SSH yönlendirmesi baytları hangi soketin taşıdığını değiştirir, istemcinin beklemesi gereken kimliği değil. Bu iki fikir ayrıldığında hata artık bir TLS arızası gibi görünmez.

Yönlendirme bir yetkilendirme de değildir. PostgreSQL, SSH sunucusunun kurduğu bağlantıya kendi kurallarını uygulamaya devam eder, bu yüzden bir şeyi değiştirmeden önce taşıma katmanı ile veritabanı katmanını ayrı tutun.

Yönlendirmeyi yalnızca loopback'e bağlayın

Dinleyici QGIS makinesinde olmalı ve başka hiçbir yerde bulunmamalıdır. 127.0.0.1'i açıkça belirtmek onu diğer arayüzlerden uzak tutar; bağlama adresi atlanırsa, SSH istemcisinin ağ geçidi ayarlarına bağlı olarak bağlantı noktası dışarı açılabilir.

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

İkinci iki noktadan sonraki hedef SSH sunucusu tarafından çözülür, bu yüzden bu örnek PostgreSQL'in sshd ile aynı ana bilgisayarda olduğunu varsayar; başka bir makinedeki veritabanı o adrese ve izinlerine ihtiyaç duyar. Oturumu -N ile başlatın; böylece hiçbir kabuk açılmaz, ana bilgisayar anahtarı doğrulamasına dokunmayın ve QGIS'i suçlamadan önce dinleyicinin göründüğünü doğrulayın. Bağlantı noktası zaten kullanımdaysa yönlendirme sorgu anında değil, başlangıçta başarısız olur.

Adı ve soketi tek bir hizmet girdisine koyun

Bir hizmet dosyası, aynı bağlantının bir doğrulama adı ve farklı bir soket hedefi taşımasını sağlar. Girdiyi libpq'nin hizmetleri aradığı yere kaydedin veya PGSERVICEFILE ayarını ona yönlendirin.

[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

Burada host sertifika denetimleri için kullanılan kimliği korurken hostaddr paketleri yönlendirilen loopback bağlantı noktasına gönderir ve bu düzenin çalışması için ikisi de gereklidir. gssencmode=disable aksi hâlde önce GSSAPI şifrelemesini görüşecek derlemelerde önemlidir, çünkü bu yol az önce ayarlanan TLS ayarlarını yok sayar. QGIS'in PostgreSQL bağlantı iletişim kutusundan hizmete adıyla başvurun ve parolayı paylaşılan bir dosyanın içinde değil, olağan istem yoluyla verin. Yukarıdaki adlar ve yollar yer tutucudur; bunları kendi onaylanmış değerlerinizle değiştirin.

PostgreSQL tünelden sonra hâlâ neyi denetler

Sunucu, SSH ana bilgisayarından, bu düzende loopback'ten gelen bir bağlantı görür ve bunu sırayla ana bilgisayar tabanlı kimlik doğrulama kurallarıyla eşleştirir. Veritabanı rolünüzün yine de kimlik doğrulaması gerekir ve SSH oturumu kendi başına hiçbir veritabanı kimliği vermez. Sunucunun neye inandığını doğrulayın, istemcinin ne varsaydığını değil.

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

İş bitince yönlendirme oturumunu kapatın; yerel girdi o zaman çalışmayı bırakır ve başka hiçbir şey değişmez. Veritabanına giden tek bir yol, tüm GIS istemcisi için VPN değildir, ve onu VPN gibi görmek, sonraki bağlantının yanlış teşhis edilmesinin nedenidir.

İlgili makaleler