VPN 越しに QGIS を PostGIS へ接続する：手順を追って

QGIS はデータプロバイダーが到達できる経路をそのまま読みます。ですから VPN がつながっていることは設定の半分にすぎません。トンネルはデスクトップに経路と名前解決の方針を与えますが、プロジェクトにはサービスのエンドポイント、プロバイダーのプロトコル、そしてサービスが受け入れる資格情報が別に要ります。これらは三つの別項目であり、VPN の公開リスナーをデータベース欄に打ち込んでもどれにも当たりません。本稿は PostGIS レイヤー一つを QGIS のフォームから返ってくる行まで追い、各手順が何を証明するのかを境界として示します。

VPN ではなくレイヤーから始める

レイヤーの種類ごとに到達するエンドポイントの種類が違います。PostGIS レイヤーはホスト、ポート、データベース、ロールを指定して PostgreSQL 接続を開きます。WMS や WFS のレイヤーはサービスの URL を取得し、その後で capabilities 文書を解析します。ネットワーク共有上の shapefile は、OS が開けるファイルパスだけで足ります。三つは別の仕組みなので、どれを調べているのか分かるまで、空のプロジェクトは何も教えてくれません。

エンドポイント、ポート、必要な識別子、自分のアカウントに適用されるアクセス方針を GIS 担当者に確認してください。配備がプライベート DNS や証明書の名前検査に依存しているなら、サービスのホスト名は発行されたとおりに保ちます。他利用者の保存済み接続からコピーしたホストアドレスを再利用するのは、応答はするが古いデータベースを持つマシンに最短でたどり着く方法です。

経路、許可された資源、名前解決は VPN を運用する側の責任です。データソースのフォームは、トンネルプロファイルが一度も配布していない経路を追加できませんし、ゲートウェイの方針を広げることもできません。ホスト名が解決し、ポートが応答したなら、問題のネットワーク側は片づいています。

運用者が発行したプライベートなエンドポイントを入力する

QGIS の PostgreSQL フォームは 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 モードはトンネルと切り離しておく

VPN 製品名の SSL はデータベースのセッションではなくトンネルを指します。QGIS は PostgreSQL の SSL モードを 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 は経路かファイアウォール規則の欠落を意味し、ゲートウェイ側の修正です。psql の TLS エラーは証明書か名前が誤っているという意味で、password authentication failed は PostgreSQL に到達しており資格情報が問題だという意味です。WMS レイヤーなら curl の呼び出しが QGIS の解析する capabilities XML を返すので、その出力に HTML のログインページが出ていれば空のレイヤーの説明がすぐにつきます。

タイムアウトに比べれば PostgreSQL のエラーは良い知らせです。宛先が応答した証拠で、チケットはネットワーク班からデータベース管理者や GIS 管理者へ移ります。この区別を報告に残せば一往復を省けます。

プロジェクトが空のレイヤーで開くとき

QGIS の中で、何かを入れ直す前にレイヤーの保存済みソースを確認してください。レイヤー属性にはプロジェクトが保存した接続文字列がそのまま出ます。古いホストを持つ重複した接続項目は、以前のオフィスネットワークのよくある残りかすです。接続を直したあとにプロジェクトを再読み込みしてもプロバイダーを必ず読み直すとは限らないので、レイヤーを削除し、修正した接続から追加し直します。

次に、認証設定が一覧にあるだけでなく、そのレイヤーに結び付いていることを確かめます。別の認証設定で保存されたレイヤーはブラウザーパネルで黙って失敗し、単体の psql テストは通ります。

レイヤーが読み込めたら、ファイルにだけ相対パスを使う形でプロジェクトを保存し、サービス接続はエンドポイントの名前で保ちます。プロジェクトを引き継いだ次の人は、チケットを開かずに、壊れたレイヤーがどのホストを想定していたかを言えます。