GeoServer en PostGIS: die VPN-pad wat saak maak, is dié van die bediener

Jy maak die laag in QGIS oop en dit teken. ’n Kollega op dieselfde VPN kry ’n fout vir dieselfde laag. Iemand lei daaruit af dat die VPN stukkend is, en die volgende uur gaan op aan die skuif van ’n databasis of die blootstelling van ’n poort wat nie een van die twee ooit nodig gehad het nie. Die versoek vanaf die werkskerm en die navraag wat GeoServer aan PostGIS maak, vertrek van verskillende masjiene, in verskillende netwerk-naamruimtes, met verskillende geloofsbriewe. Om daardie twee paaie te skei, is die grootste deel van die diagnose.

Twee verbindings, twee oorspronge

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

Die tweede pyl erf nie die eerste rekenaar se tonnel nie. ’n GeoServer in ’n houer het die houer se netwerkstapel, nie dié van die gasheer nie, en ’n houer op ’n oorbrugde netwerk kan ’n databasis bereik wat die gasheer nie bereik nie, of omgekeerd. Dus kan dieselfde gebruiker in een sessie slaag en misluk, afhangend van of die antwoord uit die kas of uit ’n vars navraag gekom het.

Vind die stap wat werklik misluk het

’n Afwysing op diensvlak, ’n beeldversoek wat nie sy datastoor bereik nie, en ’n toestemmingsprobleem in een laag lyk in ’n blaaier-oortjie dieselfde en heeltemal anders in die bedienerlog. Vra vir die spesifieke bewerking en lees dan GeoServer se eie gebeurtenis vir dieselfde tydstempel.

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"

’n 200 van die tweede versoek met ’n aanneemlike beeld bewys dat die datastoor geantwoord het. ’n 200 met ’n diens-uitsondering-dokument bewys dat dit nie het nie, en die uitsonderingsteks noem gewoonlik die stoor eerder as die kliënt.

Lees die datastoor van die bediener se kant

Die PostGIS-verwysing van GeoServer lys wat die stoor nodig het: gasheer, poort, databasis en geloofsbriewe. Dit alles beskryf die verbinding wat GeoServer oopmaak. Niks daarvan beskryf ’n aanmelding deur die werkskermkliënt nie. Lees daardie vier velde as ’n stelling oor die bediener se netwerkkonteks, en die hele klas van «dit werk vir hulle»-kaartjies word hanteerbaar.

Daarom is localhost in ’n datastoor so ’n algemene fout. Dit beteken die GeoServer-proses se eie netwerkkonteks. As GeoServer in Docker loop terwyl PostGIS op die gasheer loop, localhost wys binne die houer en vind niks, en geen VPN-opstelling verander dit nie.

Kontroleer op die bediener die roete, die luisteraar en die stawingsbeleid in daardie volgorde. PostgreSQL se gasheer-gebaseerde stawing pas die bronadres wat dit sien, wat ’n poort kan vertaal, so om ’n kliënt-VPN-poel by die HBA-lêer te voeg, maak selde ’n verbinding aan die bedienerkant reg. Toets soos die bediener dit sou doen: dieselfde gasheer, dieselfde poort, dieselfde gebruiker. As daardie toets slaag terwyl GeoServer steeds misluk, is die verskil die proseskonteks en nie die databasis nie.

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

Poel en kas hou toestand oor veranderinge heen

Verbindingspoele van die datastoor hou sokkette oop. ’n Tonnel wat ’n uur ná die skepping van die poel opgekom het, gee nie noodwendig vir die poel ’n nuwe pad nie, en ’n ledige verbinding kan op ’n dooie roete sit totdat ’n validering of ’n tydperk dit beëindig. Kontroleer die geïnstalleerde stoor se valideringsinstellings eerder as om herstel aan te neem, en vermy die versoeking om die hele diens te herbegin voordat jy weet watter laag misluk het.

Tegel-kas skep die spieëlbeeld van daardie probleem: hulle kan ’n korrek lykende kaart lank nadat die databasisverbinding gebreek het, bedien. Om die kas skoon te maak om «te kyk of dit help», vernietig die een stuk bewyse wat jou sou gesê het watter pad lewendig was.

Dra oor met albei oorspronge genoem

Die beskrywing wat ’n vinnige regstelling kry, noem twee dinge: die kliëntversoek wat GeoServer bereik het, en die backend-bewerking wat GeoServer nie kon voltooi nie. Met albei kan die regte eienaar die pad wat misluk het, herstel. Met net die eerste is die natuurlike regstelling om die databasis publiek bloot te stel, wat die kaartjie oplos deur ’n slegter probleem te skep.

Let op die laag, die antwoordkode, die uitsondering aan die bedienerkant en die houer of gasheer wat dit geproduseer het. Dit is vier reëls, en dit verwyder die dubbelsinnigheid heeltemal.