GeoServer i PostGIS: liczy się ścieżka VPN serwera

Otwierasz warstwę w QGIS i renderuje się. Kolega w tej samej sieci VPN dostaje błąd dla tej samej warstwy. Ktoś wnioskuje, że VPN jest zepsuty, a następna godzina mija na przenoszeniu bazy danych albo wystawianiu portu, który nigdy nie był potrzebny. Żądanie z komputera i zapytanie, które GeoServer wysyła do PostGIS, wychodzą z różnych maszyn, w różnych przestrzeniach nazw sieci, z różnymi poświadczeniami. Rozdzielenie tych dwóch ścieżek to większość diagnozy.

Dwa połączenia, dwa źródła

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

Druga strzałka nie dziedziczy tunelu pierwszego komputera. GeoServer w kontenerze ma stos sieciowy kontenera, nie hosta, a kontener w sieci mostkowej może dotrzeć do bazy, do której host nie dociera, lub odwrotnie. Ten sam użytkownik może więc odnieść sukces i ponieść porażkę w jednej sesji, zależnie od tego, czy odpowiedź przyszła z pamięci podręcznej, czy z nowego zapytania.

Znajdź krok, który naprawdę zawiódł

Odmowa na poziomie usługi, żądanie obrazu, które nie dociera do swojego magazynu danych, i problem z uprawnieniami w jednej warstwie wyglądają podobnie na karcie przeglądarki, a zupełnie inaczej w logu serwera. Poproś o konkretną operację, a potem przeczytaj własne zdarzenie GeoServer dla tego samego znacznika czasu.

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"

Odpowiedź 200 na drugie żądanie z wiarygodnym obrazem dowodzi, że magazyn danych odpowiedział. Odpowiedź 200 z dokumentem wyjątku usługi dowodzi, że nie odpowiedział, a tekst wyjątku zwykle wskazuje magazyn, a nie klienta.

Odczytaj magazyn danych od strony serwera

Dokumentacja PostGIS GeoServer wymienia to, czego potrzebuje magazyn: host, port, bazę danych i poświadczenia. To wszystko opisuje połączenie, które otwiera GeoServer. Nic z tego nie opisuje logowania przez klienta na komputerze. Czytaj te cztery pola jako stwierdzenie o kontekście sieciowym serwera, a cała klasa zgłoszeń „u nich działa” staje się możliwa do opanowania.

Dlatego localhost w magazynie danych jest tak częstym błędem. Oznacza kontekst sieciowy samego procesu GeoServer. Jeśli GeoServer działa w Dockerze, a PostGIS na hoście, localhost wskazuje wnętrze kontenera i niczego nie znajduje, i żadna konfiguracja VPN tego nie zmieni.

Na serwerze sprawdź trasę, nasłuch i politykę uwierzytelniania w tej kolejności. Uwierzytelnianie PostgreSQL oparte na hoście porównuje adres źródłowy, który widzi, a brama może go przetłumaczyć, więc dodanie puli VPN klientów do pliku HBA rzadko naprawia połączenie po stronie serwera. Testuj tak, jak zrobiłby to serwer: ten sam host, ten sam port, ten sam użytkownik. Jeśli ten test się udaje, a GeoServer nadal zawodzi, różnica tkwi w kontekście procesu, a nie w bazie danych.

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

Pule i pamięci podręczne zachowują stan między zmianami

Pule połączeń magazynu danych trzymają gniazda otwarte. Tunel, który wstał godzinę po utworzeniu puli, niekoniecznie daje puli nową ścieżkę, a bezczynne połączenie może siedzieć na martwej trasie, dopóki walidacja lub limit czasu go nie zamknie. Sprawdź ustawienia walidacji zainstalowanego magazynu, zamiast zakładać odzyskanie, i unikaj pokusy ponownego uruchomienia całej usługi, zanim nie wiesz, która warstwa zawiodła.

Pamięci podręczne kafli tworzą odwrotność tego problemu: mogą serwować poprawnie wyglądającą mapę długo po tym, jak połączenie z bazą danych się zerwało. Wyczyszczenie pamięci podręcznej, żeby „zobaczyć, czy to pomoże”, niszczy jedyny dowód, który powiedziałby ci, która ścieżka była żywa.

Przekaż sprawę, nazywając oba źródła

Opis, który przynosi szybką naprawę, nazywa dwie rzeczy: żądanie klienta, które dotarło do GeoServer, i operację zaplecza, której GeoServer nie zdołał ukończyć. Mając oba, właściwy właściciel może naprawić ścieżkę, która zawiodła. Mając tylko pierwsze, naturalną naprawą jest publiczne wystawienie bazy danych, co rozwiązuje zgłoszenie, tworząc gorszy problem.

Zapisz warstwę, kod odpowiedzi, wyjątek po stronie serwera oraz kontener lub host, który go wygenerował. To cztery linie i całkowicie usuwają niejednoznaczność.