Ansluta QGIS till PostGIS bakom en VPN: steg för steg

QGIS läser varje sökväg som dess dataleverantörer kan nå, så en VPN som är uppe är bara halva uppsättningen. Tunneln ger skrivbordet en rutt och en namnupplösningspolicy; projektet behöver fortfarande tjänstens slutpunkt, leverantörens protokoll och de inloggningsuppgifter som tjänsten accepterar. Det är tre separata fält, och att skriva VPN:ens publika lyssnare i ett databasfält är inget av dem. Den här genomgången följer ett PostGIS-lager från QGIS-formuläret till en returnerad rad och namnger den gräns som varje steg bevisar.

Börja med lagret, inte med VPN:en

Varje lagertyp når ett annat slags slutpunkt. Ett PostGIS-lager öppnar en PostgreSQL-anslutning med värd, port, databas och roll. Ett WMS- eller WFS-lager hämtar en tjänste-URL och tolkar sedan ett kapabilitetsdokument. En shapefile på en nätverksdelning behöver bara en filsökväg som operativsystemet kan öppna. Eftersom det är tre olika mekanismer säger ett tomt projekt ingenting förrän du vet vilken du felsöker.

Fråga GIS-operatören om slutpunkten, porten, den identitet som krävs och den åtkomstpolicy som gäller för ditt konto. Håll tjänstens värdnamn exakt som det utfärdades när driftsättningen beror på privat DNS eller på namnkontroller i certifikatet. Att återanvända en värdadress kopierad från en annan användares sparade anslutning är den snabbaste vägen till en maskin som svarar men har en äldre databas.

Rutter, tillåtna resurser och namnuplösning tillhör den som driver VPN:en. Ett datakälleformulär kan inte installera en rutt som tunnelprofilen aldrig skickade, och det kan inte vidga en gatewaypolicy. När värden löses upp och porten svarar är nätverkssidan av problemet klar.

Ange den privata slutpunkt som operatören utfärdade

PostgreSQL-formuläret i QGIS speglar de fält som libpq förväntar sig, så fyll i det i samma ordning som en kommandoradsanslutning skulle göra. Tjänst och värd tar databasmaskinen, port tar den lyssnare som servern faktiskt öppnar, och databas tar den specifika katalogen i stället för serverns standard. Spara lösenordet i en autentiseringskonfiguration i stället för i projektfilen, så att ett delat projekt inte bär inloggningsuppgifter.

Skilj de två namnen innan du skriver något. Gatewaynamnet hör hemma i VPN-klienten och databasnamnet i QGIS, och de är sällan samma värd.

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

Om databasen ligger på en annan maskin bakom gatewayen måste namnet i formuläret vara den maskinen. Privat DNS genom tunneln är det som får namnet att fungera, och ett projekt som bara löses upp medan du är ansluten beter sig korrekt i stället för att cacha dåligt.

Håll databasens TLS-läge skilt från tunneln

SSL i ett VPN-produktnamn beskriver tunneln, inte databassessionen. QGIS skickar vidare PostgreSQL SSL-läget till libpq, och det läget styr om klienten verifierar serverns certifikat och om den kontrollerar värdnamnet i det. verify-fullgör båda, därför är det läget som är värt att behålla när certifikatet bär tjänstens namn.

Att sänka läget till disable eftersom tunneln redan är krypterad tar bort kontrollen att servern du nådde är den du bad om. När verifieringen misslyckas är den vanliga orsaken namnavvikelse eller ett saknat rotcertifikat, och båda kan åtgärdas utan att försvaga anslutningen. Peka sslrootcert mot det CA som operatören publicerar och håll värdnamnet i formuläret identiskt med namnet i certifikatet.

En tunnel med privat rutt och en databas med giltigt certifikat kan fortfarande misslyckas på rollen. Applikationens inloggningsuppgifter är skilda från VPN:ens, och ett konto som autentiserar mot gatewayen har inga implicita rättigheter i PostgreSQL.

Testa varje gräns i tur och ordning och läs det första felet

Arbeta från klienten och utåt i fast ordning: namnuplösning, TCP-nåbarhet, TLS, autentisering och sedan själva frågan. Det första steget som misslyckas är det enda som är värt att rapportera, och att hoppa framåt ger felmeddelanden från en gräns du ännu inte nått. Fyra kommandon täcker de fyra första stegen.

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

Ett tomt svar från getent är ett upplösningsproblem, inte ett databasproblem. En avvisad eller utgången nc betyder att en rutt eller en brandväggsregel saknas, vilket är en rättning på gatewaysidan. Ett TLS-fel från psql betyder att certifikatet eller namnet är fel, medan password authentication failed betyder att du nådde PostgreSQL och att inloggningsuppgifterna är problemet. För ett WMS-lager ger curl anropet kapabilitets-XML:en som QGIS skulle tolka, så en HTML-inloggningssida i den utskriften förklarar genast ett tomt lager.

Ett PostgreSQL-fel är goda nyheter jämfört med en timeout. Det bevisar att målet svarade, vilket flyttar ärendet från nätverksteamet till databas- eller GIS-administratören. Att behålla den skillnaden i rapporten sparar en runda.

När projektet öppnas med tomma lager

Kontrollera lagrets sparade källa i QGIS innan du skriver in något igen. Lageregenskaperna visar den exakta anslutningssträngen som projektet sparade, och en dubblerad anslutningspost med en äldre värd är en vanlig rest från ett tidigare kontorsnätverk. Att ladda om projektet efter att en anslutning rättats läser inte alltid leverantören igen, så ta bort lagret och lägg till det igen från den rättade anslutningen.

Bekräfta sedan att autentiseringskonfigurationen är den som är kopplad till lagret, inte bara den som finns i listan. Ett lager sparat med en annan autentiseringskonfiguration misslyckas tyst i webbläsarpanelen medan det separata psql testet går igenom.

När lagret laddas, spara projektet med relativa sökvägar bara för filer och håll tjänsteanslutningar namngivna efter sin slutpunkt. Nästa person som ärver projektet kan då se vilken värd ett trasigt lager förväntade sig utan att öppna ett ärende.