GeoServer e PostGIS: o caminho VPN que importa é o do servidor

O facto de o seu portátil chegar ao GeoServer não diz nada sobre o GeoServer chegar ao PostGIS. Compare as duas origens, a fronteira da cache e a própria fonte do armazenamento de dados.

Abre a camada no QGIS e ela é desenhada. Um colega na mesma VPN recebe um erro para a mesma camada. Alguém conclui que a VPN está avariada, e a hora seguinte gasta-se a mover uma base de dados ou a expor uma porta que nunca precisou de nenhuma das duas coisas. O pedido do ambiente de trabalho e a consulta que o GeoServer faz ao PostGIS partem de máquinas diferentes, em espaços de nomes de rede diferentes, com credenciais diferentes. Separar estes dois caminhos é a maior parte do diagnóstico.

Duas ligações, duas origens

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

A segunda seta não herda o túnel do primeiro computador. Um GeoServer num contentor tem a pilha de rede do contentor, não a do anfitrião, e um contentor numa rede em ponte pode alcançar uma base de dados que o anfitrião não alcança, ou o contrário. Assim, o mesmo utilizador pode acertar e falhar dentro de uma sessão, consoante a resposta veio da cache ou de uma consulta nova.

What you testedWhat it proves
Portal page or GetCapabilitiesHTTP reachability to GeoServer only
A tile served from cachenothing about the database
GetMap for an uncached layera datastore query had to happen

Encontrar o passo que falhou de facto

Uma rejeição ao nível do serviço, um pedido de imagem que não chega ao seu armazenamento de dados e um problema de permissões numa camada parecem iguais num separador do navegador e completamente diferentes no registo do servidor. Peça a operação concreta e depois leia o evento do próprio GeoServer para o mesmo carimbo temporal.

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"

Um 200 do segundo pedido com uma imagem plausível prova que o armazenamento de dados respondeu. Um 200 com um documento de exceção de serviço prova que não respondeu, e o texto da exceção nomeia normalmente o armazenamento em vez do cliente.

Ler o armazenamento de dados do lado do servidor

A referência PostGIS do GeoServer lista o que o armazenamento precisa: anfitrião, porta, base de dados e credenciais. Tudo isso descreve a ligação que o GeoServer abre. Nada disso descreve um início de sessão pelo cliente de ambiente de trabalho. Leia esses quatro campos como uma afirmação sobre o contexto de rede do servidor, e toda a classe de pedidos «na deles funciona» torna-se tratável.

É por isso que localhost num armazenamento de dados é um erro tão comum. Significa o contexto de rede do próprio processo do GeoServer. Se o GeoServer corre em Docker enquanto o PostGIS corre no anfitrião, localhost aponta para dentro do contentor e não encontra nada, e nenhuma configuração de VPN muda isso.

No servidor, verifique a rota, o listener e a política de autenticação por essa ordem. A autenticação baseada no anfitrião do PostgreSQL compara o endereço de origem que observa, que um gateway pode traduzir, pelo que acrescentar um conjunto de VPN de clientes ao ficheiro HBA raramente corrige uma ligação do lado do servidor. Teste como o servidor o faria: mesmo anfitrião, mesma porta, mesmo utilizador. Se esse teste passar enquanto o GeoServer continua a falhar, a diferença está no contexto do processo e não na base de dados.

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

Os conjuntos e as caches guardam estado entre mudanças

Os conjuntos de ligações do armazenamento de dados mantêm sockets abertos. Um túnel que subiu uma hora depois de o conjunto ter sido criado não dá necessariamente ao conjunto um caminho novo, e uma ligação inativa pode ficar numa rota morta até que uma validação ou um tempo limite a encerre. Verifique as definições de validação do armazenamento instalado em vez de assumir a recuperação, e evite a tentação de reiniciar todo o serviço antes de saber que camada falhou.

As caches de mosaicos criam a imagem espelhada desse problema: podem servir um mapa de aspeto correto muito depois de a ligação à base de dados se ter quebrado. Limpar a cache para «ver se ajuda» destrói a única prova que lhe diria qual caminho estava vivo.

Passar o caso nomeando as duas origens

A descrição que obtém uma correção rápida nomeia duas coisas: o pedido do cliente que chegou ao GeoServer e a operação de backend que o GeoServer não conseguiu completar. Com ambas, o responsável certo pode reparar o caminho que falhou. Com apenas a primeira, a correção natural é expor a base de dados publicamente, o que resolve o pedido criando um problema pior.

Anote a camada, o código de resposta, a exceção do lado do servidor e o contentor ou anfitrião que a produziu. São quatro linhas, e eliminam a ambiguidade por completo.

Artigos relacionados