Подключение QGIS к PostGIS за VPN: шаг за шагом

QGIS читает любой путь, до которого дотягиваются его поставщики данных, поэтому работающий VPN — лишь половина настройки. Туннель даёт рабочему столу маршрут и политику разрешения имён; проекту по-прежнему нужны конечная точка службы, протокол поставщика и учётные данные, которые служба примет. Это три отдельные записи, и ввод публичного слушателя VPN в поле базы данных не является ни одной из них. Это руководство прослеживает один слой PostGIS от формы QGIS до возвращённой строки и называет границу, которую доказывает каждый шаг.

Начинайте со слоя, а не с VPN

Каждый тип слоя достигает своего вида конечной точки. Слой PostGIS открывает соединение PostgreSQL с хостом, портом, базой данных и ролью. Слой WMS или WFS получает URL службы и затем разбирает документ возможностей. Файл shapefile в сетевом ресурсе требует лишь пути к файлу, который операционная система может открыть. Поскольку это три разных механизма, пустой проект ничего не скажет, пока вы не поймёте, что именно отлаживаете.

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

Маршруты, разрешённые ресурсы и разрешение имён принадлежат тому, кто обслуживает VPN. Форма источника данных не может установить маршрут, который профиль туннеля никогда не отправлял, и не может расширить политику шлюза. Когда хост разрешается, а порт отвечает, сетевая сторона задачи закрыта.

Введите частную конечную точку, выданную оператором

Форма PostgreSQL в QGIS повторяет поля, которых ждёт libpq, поэтому заполняйте её в том же порядке, что и подключение из командной строки. Служба и хост принимают машину базы данных, порт принимает слушателя, который сервер действительно открывает, а база данных принимает конкретный каталог вместо значения по умолчанию. Храните пароль в конфигурации проверки подлинности, а не в файле проекта, чтобы общий проект не нёс учётные данные.

Разделите два имени, прежде чем что-то вводить. Имя шлюза относится к клиенту VPN, а имя базы данных — к QGIS, и они редко совпадают.

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

Если база данных находится на другой машине за шлюзом, имя в форме должно быть этой машиной. Именно частный DNS через туннель заставляет имя работать, и проект, который разрешается только при подключении, ведёт себя правильно, а не кэширует плохо.

Держите режим TLS базы данных отдельно от туннеля

SSL в названии продукта VPN описывает туннель, а не сеанс базы данных. QGIS передаёт режим SSL PostgreSQL в libpq, и этот режим определяет, проверяет ли клиент сертификат сервера и проверяет ли имя хоста в нём. verify-fullделает и то, и другое, поэтому это режим, который стоит сохранять, когда сертификат несёт имя службы.

Понижение режима до disable из-за того, что туннель уже зашифрован, убирает проверку того, что достигнутый сервер — это запрошенный сервер. Когда проверка не проходит, обычная причина — несовпадение имён или отсутствующий корневой сертификат, и обе исправимы без ослабления соединения. Направьте sslrootcert на CA, который публикует оператор, и держите имя хоста в форме идентичным имени в сертификате.

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

Проверяйте каждую границу по порядку и читайте первый отказ

Работайте от клиента наружу в фиксированном порядке: разрешение имён, доступность TCP, TLS, проверка подлинности и затем сам запрос. Первый неудачный шаг — единственный, о котором стоит сообщать, а забегание вперёд даёт сообщения об ошибках с границы, до которой вы ещё не дошли. Четыре команды покрывают первые четыре шага.

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

Пустой ответ от getent — это проблема разрешения имён, а не проблема базы данных. Отклонённый или истёкший nc означает, что отсутствует маршрут или правило firewall, и это исправляется на стороне шлюза. Ошибка TLS от psql означает, что сертификат или имя неверны, тогда как password authentication failed означает, что вы дошли до PostgreSQL и проблема в учётных данных. Для слоя WMS вызов curl возвращает XML возможностей, который QGIS разбирал бы, поэтому HTML-страница входа в этом выводе сразу объясняет пустой слой.

Ошибка PostgreSQL — хорошая новость по сравнению с тайм-аутом. Она доказывает, что адресат ответил, и это переносит заявку от сетевой команды к администратору базы данных или GIS. Сохранение этого различия в отчёте экономит один круг.

Когда проект открывается с пустыми слоями

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

Затем убедитесь, что конфигурация проверки подлинности — та, что прикреплена к слою, а не просто присутствует в списке. Слой, сохранённый с другой конфигурацией проверки подлинности, тихо отказывает на панели браузера, тогда как отдельная проверка psql проходит.

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