Падключыце 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 тэст праходзіць.

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