GeoServer und PostGIS: Der VPN-Pfad, auf den es ankommt, ist der des Servers

Sie öffnen den Layer in QGIS, und er wird gerendert. Ein Kollege im selben VPN bekommt für denselben Layer eine Fehlermeldung. Jemand schließt daraus, das VPN sei kaputt, und die nächste Stunde geht damit drauf, eine Datenbank zu verschieben oder einen Port freizugeben, der beides nie gebraucht hätte. Die Anfrage vom Desktop und die Abfrage, die GeoServer an PostGIS schickt, starten auf verschiedenen Maschinen, in verschiedenen Netzwerk-Namespaces, mit verschiedenen Zugangsdaten. Diese beiden Pfade zu trennen, ist der größte Teil der Diagnose.

Zwei Verbindungen, zwei Ursprünge

QGIS  ->  client's permitted path (often the VPN)  ->  GeoServer listener
GeoServer -> server's permitted path  ->  PostGIS listener

Der zweite Pfeil erbt nicht den Tunnel des ersten Rechners. Ein GeoServer in einem Container hat den Netzwerk-Stack des Containers, nicht den des Hosts, und ein Container in einem gebrückten Netz kann eine Datenbank erreichen, die der Host nicht erreicht, oder umgekehrt. Derselbe Benutzer kann also innerhalb einer Sitzung erfolgreich sein und scheitern, je nachdem, ob die Antwort aus dem Cache oder aus einer frischen Abfrage kam.

Den Schritt finden, der wirklich gescheitert ist

Eine Ablehnung auf Dienstebene, eine Bildanfrage, die ihren Datenspeicher nicht erreicht, und ein Berechtigungsproblem in einem Layer sehen in einem Browser-Tab ähnlich aus und im Server-Log völlig anders. Fragen Sie nach der konkreten Operation und lesen Sie dann das Ereignis von GeoServer zum selben Zeitstempel.

curl -s -o /dev/null -w '%{http_code}\n' \
  "https://gis.example.com/geoserver/wms?service=WMS&version=1.3.0&request=GetCapabilities"

curl -s -o /tmp/tile.png -w '%{http_code} %{size_download}\n' \
  "https://gis.example.com/geoserver/wms?service=WMS&version=1.3.0&request=GetMap&layers=corp:parcels&bbox=-13650000,4500000,-13600000,4550000&width=256&height=256&srs=EPSG:3857&format=image/png"

Ein 200 der zweiten Anfrage mit einem plausiblen Bild beweist, dass der Datenspeicher geantwortet hat. Ein 200 mit einem Service-Exception-Dokument beweist, dass er es nicht getan hat, und der Text der Ausnahme nennt meist den Store statt den Client.

Den Datenspeicher von der Serverseite lesen

Die PostGIS-Referenz von GeoServer listet, was der Store braucht: Host, Port, Datenbank und Zugangsdaten. All das beschreibt die Verbindung, die GeoServer öffnet. Nichts davon beschreibt eine Anmeldung durch den Desktop-Client. Lesen Sie diese vier Felder als Aussage über den Netzwerkkontext des Servers, und die ganze Klasse der Tickets „bei denen läuft es“ wird handhabbar.

Deshalb ist localhost in einem Datenspeicher ein so häufiger Fehler. Er meint den Netzwerkkontext des GeoServer-Prozesses selbst. Wenn GeoServer in Docker läuft, während PostGIS auf dem Host läuft, localhost zeigt in den Container hinein und findet nichts, und keine VPN-Konfiguration ändert daran etwas.

Prüfen Sie auf dem Server die Route, den Listener und die Authentifizierungsrichtlinie, in dieser Reihenfolge. Die hostbasierte Authentifizierung von PostgreSQL gleicht die Quelladresse ab, die sie sieht, und ein Gateway kann sie übersetzen, sodass ein Client-VPN-Pool in der HBA-Datei eine serverseitige Verbindung selten repariert. Testen Sie so, wie der Server es täte: derselbe Host, derselbe Port, derselbe Benutzer. Wenn dieser Test gelingt, während GeoServer weiter scheitert, liegt der Unterschied im Prozesskontext und nicht in der Datenbank.

ip route get 10.20.5.11
ss -tnp | grep 5432
psql "host=10.20.5.11 dbname=gis user=geoserver" -c 'select 1'

Pools und Caches halten Zustand über Änderungen hinweg

Verbindungspools von Datenspeichern halten Sockets offen. Ein Tunnel, der eine Stunde nach dem Anlegen des Pools aufkam, gibt dem Pool nicht zwangsläufig einen neuen Pfad, und eine untätige Verbindung kann auf einer toten Route sitzen bleiben, bis eine Validierung oder ein Timeout sie beendet. Prüfen Sie die Validierungseinstellungen des installierten Stores, statt eine Erholung anzunehmen, und widerstehen Sie der Versuchung, den ganzen Dienst neu zu starten, bevor Sie wissen, welcher Layer gescheitert ist.

Tile-Caches erzeugen das Spiegelbild dieses Problems: Sie können eine korrekt aussehende Karte noch lange ausliefern, nachdem die Datenbankverbindung abgebrochen ist. Den Cache zu leeren, um „zu sehen, ob es hilft“, zerstört den einen Beweis, der Ihnen gesagt hätte, welcher Pfad lebendig war.

Mit beiden Ursprüngen übergeben

Die Beschreibung, die eine schnelle Lösung bekommt, nennt zwei Dinge: die Client-Anfrage, die GeoServer erreicht hat, und die Backend-Operation, die GeoServer nicht abschließen konnte. Mit beidem kann der richtige Verantwortliche den Pfad reparieren, der gescheitert ist. Mit nur dem ersten ist die naheliegende Lösung, die Datenbank öffentlich freizugeben, was das Ticket löst, indem es ein schlimmeres Problem schafft.

Notieren Sie den Layer, den Antwortcode, die serverseitige Ausnahme und den Container oder Host, der sie erzeugt hat. Das sind vier Zeilen, und sie beseitigen die Mehrdeutigkeit vollständig.