GeoServer og PostGIS: VPN-veien som betyr noe, er serverens

Du åpner laget i QGIS, og det tegnes opp. En kollega på samme VPN får en feil for samme lag. Noen konkluderer med at VPN-en er ødelagt, og den neste timen går med til å flytte en database eller åpne en port som aldri trengte noen av delene. Forespørselen fra skrivebordet og spørringen GeoServer sender til PostGIS, starter på forskjellige maskiner, i forskjellige nettverksnavnerom, med forskjellige påloggingsdetaljer. Å skille de to veiene er det meste av diagnosen.

To tilkoblinger, to opphav

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

Den andre pilen arver ikke den første datamaskinens tunnel. En GeoServer i en container har containerens nettverksstakk, ikke vertens, og en container på et broet nettverk kan nå en database som verten ikke når, eller omvendt. Dermed kan samme bruker lykkes og feile i samme økt, avhengig av om svaret kom fra cachen eller fra en fersk spørring.

Finn trinnet som faktisk feilet

En avvisning på tjenestenivå, en bildeforespørsel som ikke når datalageret sitt, og et tillatelsesproblem i ett lag ser like ut i en nettleserfane og helt forskjellige ut i serverloggen. Be om den konkrete operasjonen, og les deretter GeoServers egen hendelse for samme tidsstempel.

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"

En 200 fra den andre forespørselen med et plausibelt bilde beviser at datalageret svarte. En 200 med et service-exception-dokument beviser at det ikke gjorde det, og unntaksteksten navngir som regel storen framfor klienten.

Les datalageret fra serverens side

Den PostGIS-referansen fra GeoServer lister opp hva storen trenger: vert, port, database og påloggingsdetaljer. Alt dette beskriver tilkoblingen GeoServer åpner. Ingenting av det beskriver en innlogging fra skrivebordsklienten. Les de fire feltene som en uttalelse om serverens nettverkskontekst, og hele klassen av saker der »det funker hos dem« blir håndterbar.

Derfor er localhost i et datalager en så vanlig feil. Det betyr GeoServer-prosessens eget nettverkskontekst. Hvis GeoServer kjører i Docker mens PostGIS kjører på verten, localhost peker inn i containeren og finner ingenting, og ingen VPN-konfigurasjon endrer det.

Sjekk på serveren ruten, listeneren og autentiseringspolicyen i den rekkefølgen. PostgreSQLs vertsbaserte autentisering matcher kildeadressen den ser, som en gateway kan oversette, så å legge til en klient-VPN-pool i HBA-filen reparerer sjelden en tilkobling på serversiden. Test som serveren ville gjort: samme vert, samme port, samme bruker. Hvis den testen lykkes mens GeoServer fortsatt feiler, ligger forskjellen i prosesskonteksten og ikke i databasen.

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

Pooler og cacher holder tilstand på tvers av endringer

Tilkoblingspooler i datalageret holder sockets åpne. En tunnel som kom opp en time etter at poolen ble opprettet, gir ikke nødvendigvis poolen en ny vei, og en inaktiv tilkobling kan bli sittende på en død rute til en validering eller en timeout avslutter den. Sjekk valideringsinnstillingene til den installerte storen i stedet for å anta at den kommer seg, og unngå fristelsen til å restarte hele tjenesten før du vet hvilket lag som feilet.

Tile-cacher skaper speilbildet av det problemet: de kan servere et korrekt utseende kart lenge etter at databasetilkoblingen ble brutt. Å tømme cachen for å »se om det hjelper« ødelegger det ene beviset som ville ha fortalt deg hvilken vei som var levende.

Overlever med begge opphavene navngitt

Beskrivelsen som gir en rask retting, navngir to ting: klientforespørselen som nådde GeoServer, og backend-operasjonen GeoServer ikke kunne fullføre. Med begge kan riktig eier reparere veien som feilet. Med bare den første er den naturlige rettingen å eksponere databasen offentlig, noe som løser saken ved å skape et verre problem.

Noter laget, svarkoden, unntaket på serversiden og containeren eller verten som produserte det. Det er fire linjer, og det fjerner tvetydigheten helt.