GeoServer et PostGIS : le chemin VPN qui compte est celui du serveur

Vous ouvrez la couche dans QGIS et elle s’affiche. Un collègue sur le même VPN reçoit une erreur pour la même couche. Quelqu’un en conclut que le VPN est en panne, et l’heure qui suit passe à déplacer une base de données ou à exposer un port qui n’avait besoin ni de l’un ni de l’autre. La requête partie du poste de travail et la requête que GeoServer adresse à PostGIS quittent des machines différentes, dans des espaces de noms réseau différents, avec des identifiants différents. Séparer ces deux chemins, c’est l’essentiel du diagnostic.

Deux connexions, deux origines

QGIS  ->  client's permitted path (often the VPN)  ->  GeoServer listener
GeoServer -> server's permitted path  ->  PostGIS listener

La seconde flèche n’hérite pas du tunnel du premier ordinateur. Un GeoServer dans un conteneur possède la pile réseau du conteneur, pas celle de l’hôte, et un conteneur sur un réseau ponté peut joindre une base que l’hôte ne joint pas, ou l’inverse. Ainsi le même utilisateur peut réussir et échouer dans une seule session, selon que la réponse vient du cache ou d’une requête fraîche.

Trouver l’étape qui a réellement échoué

Un rejet au niveau du service, une requête d’image qui n’atteint pas son magasin de données et un problème de permissions sur une couche se ressemblent dans un onglet de navigateur et diffèrent totalement dans le journal du serveur. Demandez l’opération précise, puis lisez l’événement de GeoServer pour le même horodatage.

curl -s -o /dev/null -w '%{http_code}\n' \
  "https://gis.example.com/geoserver/wms?service=WMS&version=1.3.0&request=GetCapabilities"

curl -s -o /tmp/tile.png -w '%{http_code} %{size_download}\n' \
  "https://gis.example.com/geoserver/wms?service=WMS&version=1.3.0&request=GetMap&layers=corp:parcels&bbox=-13650000,4500000,-13600000,4550000&width=256&height=256&srs=EPSG:3857&format=image/png"

Un 200 renvoyé par la seconde requête avec une image plausible prouve que le magasin de données a répondu. Un 200 accompagné d’un document d’exception de service prouve qu’il n’a pas répondu, et le texte de l’exception nomme en général le magasin plutôt que le client.

Lire le magasin de données depuis le serveur

La référence PostGIS de GeoServer énumère ce dont le magasin a besoin : hôte, port, base de données et identifiants. Tout cela décrit la connexion que GeoServer ouvre. Rien de cela ne décrit une connexion depuis le client de bureau. Lisez ces quatre champs comme un énoncé sur le contexte réseau du serveur, et toute la catégorie des tickets « ça marche chez eux » devient traitable.

C’est pourquoi localhost dans un magasin de données est une erreur si courante. Cela désigne le contexte réseau propre au processus GeoServer. Si GeoServer tourne dans Docker alors que PostGIS tourne sur l’hôte, localhost pointe à l’intérieur du conteneur et ne trouve rien, et aucune configuration VPN n’y changera quoi que ce soit.

Sur le serveur, vérifiez la route, l’écouteur et la politique d’authentification, dans cet ordre. L’authentification basée sur l’hôte de PostgreSQL compare l’adresse source qu’elle observe, qu’une passerelle peut traduire, si bien qu’ajouter un pool VPN client au fichier HBA corrige rarement une connexion côté serveur. Testez comme le serveur le ferait : même hôte, même port, même utilisateur. Si ce test réussit alors que GeoServer échoue encore, la différence tient au contexte du processus, pas à la base de données.

ip route get 10.20.5.11
ss -tnp | grep 5432
psql "host=10.20.5.11 dbname=gis user=geoserver" -c 'select 1'

Les pools et les caches gardent un état à travers les changements

Les pools de connexions d’un magasin de données gardent des sockets ouvertes. Un tunnel monté une heure après la création du pool ne donne pas forcément un nouveau chemin au pool, et une connexion inactive peut rester sur une route morte jusqu’à ce qu’une validation ou un délai d’expiration la libère. Vérifiez les paramètres de validation du magasin installé au lieu de supposer un rétablissement, et évitez la tentation de redémarrer tout le service avant de savoir quelle couche a échoué.

Les caches de tuiles créent l’image inversée de ce problème : ils peuvent servir une carte d’apparence correcte longtemps après la rupture de la connexion à la base. Vider le cache pour « voir si ça aide » détruit la seule pièce à conviction qui vous aurait dit quel chemin était vivant.

Passer la main en nommant les deux origines

La description qui obtient une correction rapide nomme deux choses : la requête client qui a atteint GeoServer, et l’opération backend que GeoServer n’a pas pu terminer. Avec les deux, le bon propriétaire peut réparer le chemin qui a échoué. Avec la première seule, la correction naturelle consiste à exposer la base de données publiquement, ce qui résout le ticket en créant un problème pire.

Notez la couche, le code de réponse, l’exception côté serveur et le conteneur ou l’hôte qui l’a produite. Cela fait quatre lignes, et cela lève toute ambiguïté.