GeoServer и PostGIS: важен VPN-путь сервера

То, что ваш ноутбук попадает на GeoServer, ничего не говорит о том, попадает ли GeoServer на PostGIS. Сравните два источника, границу кэша и собственный источник хранилища данных.

Вы открываете слой в QGIS, и он отрисовывается. Коллега в том же VPN получает ошибку для того же слоя. Кто-то делает вывод, что VPN сломан, и следующий час уходит на перенос базы данных или на открытие порта, которому не нужно было ни то, ни другое. Запрос с рабочего стола и запрос, который GeoServer делает к PostGIS, уходят с разных машин, в разных сетевых пространствах имён, с разными учётными данными. Разделение этих двух путей — большая часть диагностики.

Два подключения, два источника

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

Вторая стрелка не наследует туннель первого компьютера. GeoServer в контейнере имеет сетевой стек контейнера, а не хоста, и контейнер в мостовой сети может достучаться до базы, до которой хост не достаёт, или наоборот. Поэтому один и тот же пользователь может и преуспеть, и потерпеть неудачу в одной сессии — в зависимости от того, пришёл ответ из кэша или из свежего запроса.

What you testedWhat it proves
Portal page or GetCapabilitiesHTTP reachability to GeoServer only
A tile served from cachenothing about the database
GetMap for an uncached layera datastore query had to happen

Найдите шаг, который действительно сорвался

Отказ на уровне сервиса, запрос изображения, который не доходит до своего хранилища данных, и проблема с правами в одном слое выглядят похоже на вкладке браузера и совершенно иначе в журнале сервера. Запросите конкретную операцию, а затем прочитайте собственное событие GeoServer для той же отметки времени.

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"

200 от второго запроса с правдоподобным изображением доказывает, что хранилище данных ответило. 200 с документом исключения сервиса доказывает, что не ответило, и текст исключения обычно называет хранилище, а не клиента.

Читайте хранилище данных со стороны сервера

Справочник PostGIS от GeoServer перечисляет, что нужно хранилищу: хост, порт, база данных и учётные данные. Всё это описывает подключение, которое открывает GeoServer. Ничто из этого не описывает вход с клиента на рабочем столе. Читайте эти четыре поля как утверждение о сетевом контексте сервера, и весь класс заявок «у них работает» становится разрешимым.

Именно поэтому localhost в хранилище данных — такая частая ошибка. Это означает сетевой контекст самого процесса GeoServer. Если GeoServer работает в Docker, а PostGIS — на хосте, localhost указывает внутрь контейнера и ничего не находит, и никакая настройка VPN этого не меняет.

На сервере проверьте маршрут, слушателя и политику аутентификации именно в таком порядке. Аутентификация PostgreSQL по хосту сравнивает адрес источника, который она видит, а шлюз может его транслировать, поэтому добавление пула клиентского VPN в файл HBA редко исправляет соединение на стороне сервера. Проверяйте так, как это сделал бы сервер: тот же хост, тот же порт, тот же пользователь. Если эта проверка проходит, а GeoServer всё ещё падает, разница в контексте процесса, а не в базе данных.

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

Пулы и кэши хранят состояние между изменениями

Пулы соединений хранилища данных держат сокеты открытыми. Туннель, поднявшийся через час после создания пула, не обязательно даёт пулу новый путь, а простаивающее соединение может сидеть на мёртвом маршруте, пока его не закроет проверка или тайм-аут. Проверьте настройки проверки установленного хранилища, вместо того чтобы предполагать восстановление, и избегайте соблазна перезапустить весь сервис, пока не знаете, какой слой упал.

Кэши тайлов создают зеркальное отражение этой проблемы: они могут отдавать правильно выглядящую карту ещё долго после того, как соединение с базой данных оборвалось. Очистка кэша, чтобы «посмотреть, поможет ли», уничтожает единственную улику, которая сказала бы вам, какой путь был жив.

Передавайте дело, называя оба источника

Описание, которое получает быстрое исправление, называет две вещи: клиентский запрос, дошедший до GeoServer, и серверную операцию, которую GeoServer не смог завершить. С обоими правильный владелец может починить путь, который сорвался. С одним только первым естественное исправление — открыть базу данных публично, что решает заявку, создавая проблему хуже.

Запишите слой, код ответа, исключение на стороне сервера и контейнер или хост, который его произвёл. Это четыре строки, и они полностью снимают неоднозначность.

Похожие статьи