Koble QGIS til PostGIS bak en VPN: trinn for trinn

QGIS leser enhver sti dataleverandørene når, så en VPN som er oppe er bare halve oppsettet. Tunnelen gir skrivebordet en rute og en navneoppløsningspolicy; prosjektet trenger fortsatt tjenestens endepunkt, leverandørens protokoll og de påloggingsdetaljene tjenesten godtar. Det er tre separate felt, og å skrive VPN-ens offentlige lytter i et databasefelt er ingen av dem. Denne gjennomgangen følger ett PostGIS-lag fra QGIS-skjemaet til en returnert rad og navngir grensen hvert trinn beviser.

Start med laget, ikke med VPN-en

Hver lagtype når en ulik slags endepunkt. Et PostGIS-lag åpner en PostgreSQL-tilkobling med vert, port, database og rolle. Et WMS- eller WFS-lag henter en tjeneste-URL og analyserer deretter et kapabilitetsdokument. En shapefile på en nettverksdeling trenger bare en filsti operativsystemet kan åpne. Fordi dette er tre ulike mekanismer, sier et tomt prosjekt deg ingenting før du vet hvilken du feilsøker.

Spør GIS-operatøren om endepunktet, porten, identiteten som kreves og tilgangspolicyen som gjelder for kontoen din. Hold tjenestens vertsnavn nøyaktig som utstedt når utrullingen avhenger av privat DNS eller navnekontroll i sertifikatet. Å gjenbruke en vertsadresse kopiert fra en annen brukers lagrede tilkobling er den raskeste veien til en maskin som svarer men har en eldre database.

Ruter, tillatte ressurser og navneoppløsning tilhører den som drifter VPN-en. Et datakildeskjema kan ikke installere en rute tunnelprofilen aldri sendte, og det kan ikke utvide en gateway-policy. Når verten løses opp og porten svarer, er nettverkssiden av problemet ferdig.

Skriv inn det private endepunktet operatøren utstedte

PostgreSQL-skjemaet i QGIS speiler feltene libpq forventer, så fyll det ut i samme rekkefølge som en kommandolinjetilkobling ville gjort. Tjeneste og vert tar databasemaskinen, port tar lytteren serveren faktisk åpner, og database tar den konkrete katalogen i stedet for serverens standard. Lagre passordet i en autentiseringskonfigurasjon i stedet for i prosjektfilen, slik at et delt prosjekt ikke bærer påloggingsdetaljer.

Skill de to navnene før du skriver noe. Gateway-navnet hører hjemme i VPN-klienten og databasenavnet i QGIS, og de er sjelden samme vert.

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

Hvis databasen ligger på en annen maskin bak gatewayen, må navnet i skjemaet være den maskinen. Privat DNS gjennom tunnelen er det som får navnet til å virke, og et prosjekt som bare løses opp mens du er tilkoblet, oppfører seg riktig i stedet for å cache dårlig.

Hold databasens TLS-modus atskilt fra tunnelen

SSL i et VPN-produktnavn beskriver tunnelen, ikke databasesesjonen. QGIS sender PostgreSQL SSL-modus videre til libpq, og den modusen styrer om klienten verifiserer serverens sertifikat og om den kontrollerer vertsnavnet i det. verify-fullgjør begge deler, derfor er det modusen som er verdt å beholde når sertifikatet bærer tjenestenavnet.

Å senke modusen til disable fordi tunnelen allerede er kryptert fjerner kontrollen av at serveren du nådde er serveren du ba om. Når verifiseringen feiler, er den vanlige årsaken navneavvik eller manglende rotsertifikat, og begge kan rettes uten å svekke tilkoblingen. Pek sslrootcert mot CA-en operatøren publiserer, og hold vertsnavnet i skjemaet identisk med navnet i sertifikatet.

En tunnel med privat rute og en database med gyldig sertifikat kan fortsatt feile på rollen. Applikasjonens påloggingsdetaljer er atskilt fra VPN-ens, og en konto som autentiserer mot gatewayen har ingen implisitte rettigheter i PostgreSQL.

Test hver grense i rekkefølge og les den første feilen

Arbeid fra klienten og utover i fast rekkefølge: navneoppløsning, TCP-tilgjengelighet, TLS, autentisering og deretter selve spørringen. Det første trinnet som feiler er det eneste som er verdt å rapportere, og å hoppe framover gir feilmeldinger fra en grense du ikke har nådd ennå. Fire kommandoer dekker de fire første trinnene.

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

Et tomt svar fra getent er et oppløsningsproblem, ikke et databaseproblem. En avvist eller utløpt nc betyr at en rute eller en brannmurregel mangler, noe som er en retting på gatewaysiden. En TLS-feil fra psql betyr at sertifikatet eller navnet er feil, mens password authentication failed betyr at du nådde PostgreSQL og at påloggingsdetaljene er problemet. For et WMS-lag gir curl kallet kapabilitets-XML-en QGIS ville ha analysert, så en HTML-innloggingsside i den utskriften forklarer straks et tomt lag.

En PostgreSQL-feil er gode nyheter sammenlignet med en tidsavbrudd. Den beviser at målet svarte, noe som flytter saken fra nettverksteamet til database- eller GIS-administratoren. Å beholde den forskjellen i rapporten sparer en runde.

Når prosjektet åpnes med tomme lag

Sjekk lagets lagrede kilde i QGIS før du skriver inn noe på nytt. Lagegenskapene viser den nøyaktige tilkoblingsstrengen prosjektet lagret, og en duplikattilkobling med en eldre vert er en vanlig rest fra et tidligere kontornettverk. Å laste prosjektet på nytt etter å ha rettet en tilkobling leser ikke alltid leverandøren igjen, så fjern laget og legg det til på nytt fra den rettede tilkoblingen.

Bekreft deretter at autentiseringskonfigurasjonen er den som er knyttet til laget, ikke bare en som finnes i listen. Et lag lagret med en annen autentiseringskonfigurasjon feiler stille i nettleserpanelet mens den separate psql testen består.

Når laget lastes, lagre prosjektet med relative stier bare for filer og hold tjenestetilkoblinger navngitt etter endepunktet sitt. Den neste personen som arver prosjektet kan da se hvilken vert et ødelagt lag forventet uten å åpne en sak.