Připojte QGIS k PostGIS za VPN: krok za krokem

QGIS čte každou cestu, na kterou jeho poskytovatelé dat dosáhnou, takže zapnutá VPN je jen polovina nastavení. Tunel dá počítači trasu a politiku překladu jmen; projekt stále potřebuje koncový bod služby, protokol poskytovatele a přihlašovací údaje, které služba přijme. To jsou tři samostatné položky a napsat veřejný posluchač VPN do pole databáze není ani jedna z nich. Tento postup sleduje jednu vrstvu PostGIS od formuláře v QGIS až po vrácený řádek a pojmenovává hranici, kterou každý krok prokazuje.

Začněte vrstvou, ne VPN

Každý typ vrstvy dosahuje jiného druhu koncového bodu. Vrstva PostGIS otevírá připojení PostgreSQL s hostitelem, portem, databází a rolí. Vrstva WMS nebo WFS stahuje URL služby a poté analyzuje dokument schopností. Shapefile na síťovém disku potřebuje jen cestu k souboru, kterou operační systém dokáže otevřít. Protože jde o tři různé mechanismy, prázdný projekt vám nic neřekne, dokud nevíte, který z nich ladíte.

Požádejte GIS operátora o koncový bod, port, požadovanou identitu a zásadu přístupu, která platí pro váš účet. Držte název hostitele služby přesně tak, jak byl vydán, když nasazení závisí na privátním DNS nebo na kontrolách názvu v certifikátu. Opětovné použití adresy hostitele zkopírované z uloženého připojení jiného uživatele je nejrychlejší cesta ke stroji, který odpovídá, ale má starší databázi.

Trasy, povolené zdroje a překlad jmen patří tomu, kdo VPN provozuje. Formulář zdroje dat nemůže nainstalovat trasu, kterou profil tunelu nikdy neposlal, a nemůže rozšířit zásadu brány. Když se hostitel přeloží a port odpoví, síťová strana problému je hotová.

Zadejte privátní koncový bod, který operátor vydal

Formulář PostgreSQL v QGIS zrcadlí pole, která očekává libpq, proto jej vyplňte ve stejném pořadí, v jakém by to udělalo připojení z příkazového řádku. Služba a hostitel berou stroj databáze, port bere posluchač, který server skutečně otevírá, a databáze bere konkrétní katalog místo výchozí hodnoty serveru. Uložte heslo do konfigurace ověřování, ne do souboru projektu, aby sdílený projekt nenesl přihlašovací údaj.

Oddělte oba názvy, než něco napíšete. Název brány patří do klienta VPN a název databáze do QGIS a jen zřídka jde o stejného hostitele.

VPN gateway:   vpn.gis.lab.example       (profile only, not a data source)
Database host: db.gis.lab.example:5432   (PostGIS service)
Database name: gis_prod
TLS mode:      verify-full

Pokud databáze běží na jiném stroji za branou, název ve formuláři musí být ten stroj. Privátní DNS přes tunel je to, co název zprovozní, a projekt, který se překládá jen při připojení, se chová správně, nikoli že špatně cachuje.

Držte režim TLS databáze oddělený od tunelu

SSL v názvu produktu VPN popisuje tunel, ne relaci databáze. QGIS předává režim SSL PostgreSQL do libpq a tento režim řídí, zda klient ověřuje certifikát serveru a zda kontroluje název hostitele v něm. verify-fulldělá obojí, proto je to režim, který stojí za to zachovat, když certifikát nese název služby.

Snížení režimu na disable proto, že tunel je již šifrovaný, odstraňuje kontrolu, že server, na který jste se dostali, je server, který jste žádali. Když ověření selže, obvyklou příčinou je neshoda názvů nebo chybějící kořenový certifikát a obojí lze opravit bez oslabení spojení. Nasměrujte sslrootcert na CA, kterou operátor zveřejňuje, a držte název hostitele ve formuláři shodný s názvem v certifikátu.

Tunel s privátní trasou a databáze s platným certifikátem mohou stále selhat na roli. Přihlašovací údaje aplikace jsou oddělené od údajů VPN a účet, který se ověřuje vůči bráně, nemá v PostgreSQL žádná implicitní práva.

Testujte každou hranici popořadě a čtěte první selhání

Pracujte od klienta ven v pevném pořadí: překlad jmen, dostupnost TCP, TLS, ověření a potom samotný dotaz. První krok, který selže, je jediný, který stojí za to hlásit, a přeskakování dopředu dává chybové zprávy z hranice, ke které jste ještě nedošli. Čtyři příkazy pokrývají první čtyři kroky.

getent hosts db.gis.lab.example
nc -vz db.gis.lab.example 5432
psql "host=db.gis.lab.example port=5432 dbname=gis_prod sslmode=verify-full" -c 'select 1'
curl -sS 'https://wms.gis.lab.example/ows?service=WMS&request=GetCapabilities' | head -c 200

Prázdná odpověď z getent je problém překladu, ne problém databáze. Odmítnutý nebo vypršelý nc znamená, že chybí trasa nebo pravidlo firewallu, což je oprava na straně brány. Chyba TLS z psql znamená, že certifikát nebo název jsou špatné, zatímco password authentication failed znamená, že jste dosáhli PostgreSQL a problém je v přihlašovacím údaji. U vrstvy WMS volání curl vrací XML schopností, které by QGIS analyzoval, takže HTML přihlašovací stránka v tomto výstupu okamžitě vysvětlí prázdnou vrstvu.

Chyba PostgreSQL je dobrá zpráva ve srovnání s vypršením. Dokazuje, že cíl odpověděl, což přesouvá tiket ze síťového týmu na správce databáze nebo GIS. Zachování tohoto rozlišení ve zprávě ušetří jednu cestu.

Když se projekt otevře s prázdnými vrstvami

V QGIS zkontrolujte uložený zdroj vrstvy, než cokoli znovu zadáte. Vlastnosti vrstvy ukazují přesný připojovací řetězec, který projekt uložil, a duplicitní záznam připojení se starším hostitelem je častý pozůstatek předchozí kancelářské sítě. Opětovné načtení projektu po opravě připojení ne vždy znovu přečte poskytovatele, proto vrstvu odeberte a přidejte ji znovu z opraveného připojení.

Poté ověřte, že konfigurace ověřování je ta připojená k vrstvě, ne jen přítomná v seznamu. Vrstva uložená s jinou konfigurací ověřování tiše selhává v panelu prohlížeče, zatímco samostatný psql test projde.

Když se vrstva načte, uložte projekt s relativními cestami jen pro soubory a držte připojení služeb pojmenovaná podle jejich koncového bodu. Další člověk, který projekt zdědí, pak pozná, kterého hostitele rozbitá vrstva očekávala, aniž by otevíral tiket.