Connecter QGIS à PostGIS derrière un VPN : pas à pas

QGIS lit tout chemin que ses fournisseurs de données peuvent atteindre, donc un VPN actif n’est que la moitié de la configuration. Le tunnel donne au poste une route et une politique de résolution de noms ; le projet a encore besoin du point de terminaison du service, du protocole du fournisseur et des identifiants que le service acceptera. Ce sont trois entrées distinctes, et saisir l’écouteur public du VPN dans un champ de base de données n’en est aucune. Cette visite suit une couche PostGIS du formulaire QGIS à une ligne renvoyée et nomme la frontière que chaque étape prouve.

Partez de la couche, pas du VPN

Chaque type de couche atteint un type de point de terminaison différent. Une couche PostGIS ouvre une connexion PostgreSQL avec un hôte, un port, une base de données et un rôle. Une couche WMS ou WFS récupère une URL de service puis analyse un document de capacités. Un shapefile sur un partage réseau n’a besoin que d’un chemin de fichier que le système d’exploitation peut ouvrir. Comme ce sont trois mécanismes différents, un projet vide ne vous dit rien tant que vous ne savez pas lequel vous déboguez.

Demandez à l’opérateur SIG le point de terminaison, le port, l’identité requise et la politique d’accès qui s’applique à votre compte. Gardez le nom d’hôte du service exactement tel qu’il a été émis lorsque le déploiement dépend d’un DNS privé ou de contrôles de nom dans le certificat. Réutiliser une adresse d’hôte copiée depuis la connexion enregistrée d’un autre utilisateur est le moyen le plus rapide d’atteindre une machine qui répond mais détient une base plus ancienne.

Les routes, les ressources autorisées et la résolution de noms appartiennent à qui exploite le VPN. Un formulaire de source de données ne peut pas installer une route que le profil du tunnel n’a jamais poussée, ni élargir une politique de passerelle. Quand l’hôte se résout et que le port répond, le côté réseau du problème est terminé.

Saisissez le point de terminaison privé émis par l’opérateur

Le formulaire PostgreSQL de QGIS reflète les champs attendus par libpq, remplissez-le donc dans le même ordre qu’une connexion en ligne de commande. Service et hôte prennent la machine de la base, le port prend l’écouteur que le serveur ouvre réellement, et la base prend le catalogue précis plutôt que la valeur par défaut du serveur. Stockez le mot de passe dans une configuration d’authentification plutôt que dans le fichier du projet, afin qu’un projet partagé ne transporte pas d’identifiant.

Séparez les deux noms avant de saisir quoi que ce soit. Le nom de la passerelle appartient au client VPN et le nom de la base à QGIS, et ce sont rarement le même hôte.

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

Si la base se trouve sur une autre machine derrière la passerelle, le nom du formulaire doit être cette machine. Le DNS privé à travers le tunnel est ce qui fait fonctionner le nom, et un projet qui ne résout que pendant la connexion se comporte correctement plutôt que de mal mettre en cache.

Gardez le mode TLS de la base séparé du tunnel

Le SSL dans le nom d’un produit VPN décrit le tunnel, pas la session de base de données. QGIS transmet le mode SSL PostgreSQL à libpq, et ce mode contrôle si le client vérifie le certificat du serveur et s’il contrôle le nom d’hôte qu’il contient. verify-fullfait les deux, c’est pourquoi c’est le mode à conserver quand le certificat porte le nom du service.

Abaisser le mode à disable parce que le tunnel est déjà chiffré supprime la vérification que le serveur atteint est celui demandé. Quand la vérification échoue, la cause habituelle est un écart de nom ou un certificat racine manquant, et les deux se corrigent sans affaiblir la connexion. Pointez sslrootcert vers l’AC que l’opérateur publie et gardez le nom d’hôte du formulaire identique au nom du certificat.

Un tunnel avec une route privée et une base avec un certificat valide peuvent encore échouer sur le rôle. Les identifiants de l’application sont distincts de ceux du VPN, et un compte qui s’authentifie sur la passerelle n’a aucun droit implicite dans PostgreSQL.

Testez chaque frontière dans l’ordre et lisez le premier échec

Travaillez du client vers l’extérieur dans un ordre fixe : résolution de noms, joignabilité TCP, TLS, authentification, puis la requête elle-même. La première étape qui échoue est la seule qui vaille d’être signalée, et sauter en avant produit des messages d’erreur d’une frontière que vous n’avez pas encore atteinte. Quatre commandes couvrent les quatre premières étapes.

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

Une réponse vide de getent est un problème de résolution, pas un problème de base de données. Un nc refusé ou expiré signifie qu’une route ou une règle de pare-feu manque, ce qui se corrige côté passerelle. Une erreur TLS de psql signifie que le certificat ou le nom est incorrect, tandis que password authentication failed signifie que vous avez atteint PostgreSQL et que l’identifiant est en cause. Pour une couche WMS, l’appel curl renvoie le XML de capacités que QGIS analyserait, donc une page de connexion HTML dans cette sortie explique immédiatement une couche vide.

Une erreur PostgreSQL est une bonne nouvelle comparée à un délai d’attente. Elle prouve que la destination a répondu, ce qui déplace le ticket de l’équipe réseau vers l’administrateur de base de données ou SIG. Conserver cette distinction dans le rapport épargne un aller-retour.

Quand le projet s’ouvre avec des couches vides

Dans QGIS, vérifiez la source enregistrée de la couche avant de ressaisir quoi que ce soit. Les propriétés de la couche montrent la chaîne de connexion exacte que le projet a enregistrée, et une entrée de connexion en double avec un hôte plus ancien est un reste courant d’un ancien réseau de bureau. Recharger le projet après avoir corrigé une connexion ne relit pas toujours le fournisseur, donc supprimez la couche et rajoutez-la depuis la connexion corrigée.

Confirmez ensuite que la configuration d’authentification est celle attachée à la couche, pas seulement présente dans la liste. Une couche enregistrée avec une autre configuration d’authentification échoue silencieusement dans le panneau de navigation pendant que le test psql autonome réussit.

Quand la couche se charge, enregistrez le projet avec des chemins relatifs pour les fichiers seulement et gardez les connexions de service nommées d’après leur point de terminaison. La personne suivante qui hérite du projet peut alors dire quel hôte une couche cassée attendait sans ouvrir de ticket.