QGIS hinter einem VPN mit PostGIS verbinden: Schritt für Schritt

QGIS liest jeden Pfad, den seine Datenanbieter erreichen können, ein laufendes VPN ist also nur die Hälfte der Einrichtung. Der Tunnel gibt dem Desktop eine Route und eine Namensauflösungsrichtlinie; das Projekt braucht weiterhin den Dienst-Endpunkt, das Anbieterprotokoll und die Zugangsdaten, die der Dienst akzeptiert. Das sind drei getrennte Angaben, und den öffentlichen Listener des VPN in ein Datenbankfeld zu tippen ist keine davon. Diese Anleitung verfolgt einen PostGIS-Layer vom QGIS-Formular bis zur zurückgegebenen Zeile und benennt die Grenze, die jeder Schritt beweist.

Beim Layer anfangen, nicht beim VPN

Jeder Layertyp erreicht eine andere Art von Endpunkt. Ein PostGIS-Layer öffnet eine PostgreSQL-Verbindung mit Host, Port, Datenbank und Rolle. Ein WMS- oder WFS-Layer lädt eine Dienst-URL und wertet dann ein Capabilities-Dokument aus. Ein Shapefile auf einer Netzwerkfreigabe braucht nur einen Dateipfad, den das Betriebssystem öffnen kann. Weil das drei verschiedene Mechanismen sind, sagt ein leeres Projekt nichts, bis Sie wissen, welchen davon Sie debuggen.

Fragen Sie den GIS-Betreiber nach dem Endpunkt, dem Port, der geforderten Identität und der Zugriffsrichtlinie, die für Ihr Konto gilt. Halten Sie den Dienst-Hostnamen genau so, wie er ausgegeben wurde, wenn die Bereitstellung von privatem DNS oder von Namensprüfungen im Zertifikat abhängt. Eine Hostadresse aus der gespeicherten Verbindung eines anderen Nutzers zu übernehmen ist der schnellste Weg zu einer Maschine, die antwortet, aber eine ältere Datenbank hält.

Routen, erlaubte Ressourcen und Namensauflösung gehören dem, der das VPN betreibt. Ein Datenquellenformular kann keine Route installieren, die das Tunnelprofil nie gepusht hat, und es kann keine Gateway-Richtlinie erweitern. Wenn der Host auflöst und der Port antwortet, ist die Netzwerkseite des Problems erledigt.

Den privaten Endpunkt eintragen, den der Betreiber ausgegeben hat

Das PostgreSQL-Formular in QGIS spiegelt die Felder, die libpq erwartet, füllen Sie es also in derselben Reihenfolge aus wie eine Kommandozeilenverbindung. Dienst und Host nehmen die Datenbankmaschine, Port nimmt den Listener, den der Server tatsächlich öffnet, und Datenbank nimmt den konkreten Katalog statt der Servervorgabe. Speichern Sie das Passwort in einer Authentifizierungskonfiguration statt in der Projektdatei, damit ein geteiltes Projekt keine Zugangsdaten trägt.

Trennen Sie die beiden Namen, bevor Sie etwas eintippen. Der Gateway-Name gehört in den VPN-Client und der Datenbankname in QGIS, und sie sind selten derselbe Host.

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

Steht die Datenbank auf einer anderen Maschine hinter dem Gateway, muss der Name im Formular diese Maschine sein. Privates DNS durch den Tunnel ist es, was den Namen funktionieren lässt, und ein Projekt, das nur während der Verbindung auflöst, verhält sich korrekt und cached nicht schlecht.

Den TLS-Modus der Datenbank vom Tunnel getrennt halten

Das SSL in einem VPN-Produktnamen beschreibt den Tunnel, nicht die Datenbanksitzung. QGIS reicht den PostgreSQL-SSL-Modus an libpq weiter, und dieser Modus steuert, ob der Client das Serverzertifikat prüft und ob er den Hostnamen darin kontrolliert. verify-fullmacht beides, deshalb ist er der Modus, den es sich zu behalten lohnt, wenn das Zertifikat den Dienstnamen trägt.

Den Modus auf disable herunterzustufen, weil der Tunnel ohnehin verschlüsselt ist, entfernt die Prüfung, dass der erreichte Server der angeforderte ist. Wenn die Prüfung fehlschlägt, ist die übliche Ursache eine Namensabweichung oder ein fehlendes Wurzelzertifikat, und beides lässt sich beheben, ohne die Verbindung zu schwächen. Richten Sie sslrootcert auf die CA, die der Betreiber veröffentlicht, und halten Sie den Hostnamen im Formular identisch mit dem Namen im Zertifikat.

Ein Tunnel mit privater Route und eine Datenbank mit gültigem Zertifikat können immer noch an der Rolle scheitern. Anwendungszugangsdaten sind von VPN-Zugangsdaten getrennt, und ein Konto, das sich am Gateway authentifiziert, hat keine impliziten Rechte in PostgreSQL.

Jede Grenze der Reihe nach testen und den ersten Fehler lesen

Arbeiten Sie vom Client nach außen in fester Reihenfolge: Namensauflösung, TCP-Erreichbarkeit, TLS, Authentifizierung, dann die Abfrage selbst. Der erste Schritt, der scheitert, ist der einzige, der gemeldet werden sollte, und ein Vorgriff liefert Fehlermeldungen von einer Grenze, die Sie noch nicht erreicht haben. Vier Befehle decken die ersten vier Schritte ab.

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

Eine leere Antwort von getent ist ein Auflösungsproblem, kein Datenbankproblem. Ein abgelehnter oder abgelaufener nc bedeutet, dass eine Route oder eine Firewall-Regel fehlt, was eine Korrektur auf der Gateway-Seite ist. Ein TLS-Fehler von psql bedeutet, dass Zertifikat oder Name falsch sind, während password authentication failed bedeutet, dass Sie PostgreSQL erreicht haben und die Zugangsdaten das Problem sind. Bei einem WMS-Layer liefert der curl Aufruf das Capabilities-XML, das QGIS auswerten würde, eine HTML-Anmeldeseite in dieser Ausgabe erklärt also sofort einen leeren Layer.

Ein PostgreSQL-Fehler ist eine gute Nachricht im Vergleich zu einer Zeitüberschreitung. Er beweist, dass das Ziel geantwortet hat, was das Ticket vom Netzwerkteam zum Datenbank- oder GIS-Administrator verschiebt. Diese Unterscheidung im Bericht zu behalten spart eine Runde.

Wenn das Projekt mit leeren Layern öffnet

Prüfen Sie in QGIS die gespeicherte Quelle des Layers, bevor Sie etwas neu eingeben. Die Layereigenschaften zeigen die genaue Verbindungszeichenfolge, die das Projekt gespeichert hat, und ein doppelter Verbindungseintrag mit älterem Host ist ein häufiger Rest eines früheren Büronetzwerks. Ein Neuladen des Projekts nach der Korrektur einer Verbindung liest den Anbieter nicht immer neu, entfernen Sie den Layer und fügen Sie ihn erneut aus der korrigierten Verbindung hinzu.

Bestätigen Sie dann, dass die Authentifizierungskonfiguration die dem Layer zugeordnete ist und nicht bloß in der Liste vorhanden. Ein Layer, der mit einer anderen Authentifizierungskonfiguration gespeichert wurde, scheitert im Browser-Panel still, während der eigenständige psql Test besteht.

Wenn der Layer lädt, speichern Sie das Projekt mit relativen Pfaden nur für Dateien und halten Sie Dienstverbindungen nach ihrem Endpunkt benannt. Die nächste Person, die das Projekt erbt, kann dann sehen, welchen Host ein defekter Layer erwartet hat, ohne ein Ticket zu öffnen.