Підключення 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 проходить.

Коли шар завантажиться, збережіть проєкт із відносними шляхами лише для файлів і тримайте з’єднання служб названими за їхньою кінцевою точкою. Наступна людина, яка успадкує проєкт, зможе сказати, якого хоста очікував зламаний шар, не відкриваючи заявку.