Conectar QGIS con PostGIS detrás dunha VPN: paso a paso

QGIS le calquera ruta que os seus provedores de datos poidan alcanzar, así que unha VPN activa é só a metade da configuración. O túnel dálle ao escritorio unha ruta e unha política de resolución de nomes; o proxecto aínda necesita o punto de conexión do servizo, o protocolo do provedor e as credenciais que o servizo aceptará. Son tres entradas distintas, e escribir o oínte público da VPN nun campo de base de datos non é ningunha delas. Este percorrido segue unha capa de PostGIS desde o formulario de QGIS ata unha fila devolta e nomea a fronteira que demostra cada paso.

Comece pola capa, non pola VPN

Cada tipo de capa chega a un tipo distinto de punto de conexión. Unha capa de PostGIS abre unha conexión PostgreSQL cun host, un porto, unha base de datos e un rol. Unha capa WMS ou WFS obtén un URL de servizo e despois analiza un documento de capacidades. Un shapefile nun recurso compartido de rede só necesita unha ruta de ficheiro que o sistema operativo poida abrir. Como son tres mecanismos distintos, un proxecto baleiro non lle di nada ata que sabe cal está depurando.

Pregunte ao operador de GIS polo punto de conexión, o porto, a identidade requirida e a política de acceso que se aplica á súa conta. Manteña o nome de host do servizo exactamente como se emitiu cando o despregamento depende de DNS privado ou de comprobacións de nome no certificado. Reutilizar un enderezo de host copiado da conexión gardada doutro usuario é a forma máis rápida de chegar a unha máquina que responde pero ten unha base de datos máis antiga.

As rutas, os recursos permitidos e a resolución de nomes pertencen a quen xestiona a VPN. Un formulario de orixe de datos non pode instalar unha ruta que o perfil do túnel nunca enviou, nin pode ampliar unha política de pasarela. Cando o host resolve e o porto responde, o lado de rede do problema rematou.

Introduza o punto de conexión privado que emitiu o operador

O formulario PostgreSQL de QGIS reflicte os campos que espera libpq, así que compríteo na mesma orde que seguiría unha conexión de liña de ordes. Servizo e host toman a máquina da base de datos, o porto toma o oínte que o servidor abre realmente, e a base de datos toma o catálogo concreto en lugar do valor predeterminado do servidor. Garde o contrasinal nunha configuración de autenticación e non no ficheiro do proxecto, para que un proxecto compartido non leve unha credencial.

Separe os dous nomes antes de escribir nada. O nome da pasarela pertence ao cliente VPN e o nome da base de datos pertence a QGIS, e raramente son o mesmo host.

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

Se a base de datos está noutra máquina detrás da pasarela, o nome do formulario debe ser esa máquina. O DNS privado a través do túnel é o que fai funcionar o nome, e un proxecto que só resolve mentres está conectado compórtase correctamente, non que cachee mal.

Manteña o modo TLS da base de datos separado do túnel

O SSL do nome dun produto VPN describe o túnel, non a sesión da base de datos. QGIS pasa o modo SSL de PostgreSQL a libpq, e ese modo controla se o cliente verifica o certificado do servidor e se comproba o nome de host que contén. verify-fullfai as dúas cousas, por iso é o modo que paga a pena manter cando o certificado leva o nome do servizo.

Baixar o modo a disable porque o túnel xa está cifrado elimina a comprobación de que o servidor ao que chegou é o servidor que pediu. Cando a verificación falla, a causa habitual é un desaxuste de nome ou un certificado raíz ausente, e ambos se poden corrixir sen debilitar a conexión. Apunte sslrootcert ao CA que publica o operador e manteña o nome de host do formulario idéntico ao nome do certificado.

Un túnel cunha ruta privada e unha base de datos cun certificado válido aínda poden fallar polo rol. As credenciais da aplicación son independentes das credenciais da VPN, e unha conta que se autentica na pasarela non ten dereitos implícitos en PostgreSQL.

Probe cada fronteira por orde e lea o primeiro fallo

Traballe desde o cliente cara a fóra nunha orde fixa: resolución de nomes, alcance TCP, TLS, autenticación e despois a propia consulta. O primeiro paso que falla é o único que paga a pena informar, e saltar cara a adiante produce mensaxes de erro dunha fronteira á que aínda non chegou. Catro ordes cobren os catro primeiros pasos.

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

Unha resposta baleira de getent é un problema de resolución, non un problema de base de datos. Un nc rexeitado ou esgotado significa que falta unha ruta ou unha regra de firewall, o que se corrixe no lado da pasarela. Un erro TLS de psql significa que o certificado ou o nome son incorrectos, mentres que password authentication failed significa que chegou a PostgreSQL e o problema é a credencial. Para unha capa WMS, a chamada curl devolve o XML de capacidades que QGIS analizaría, así que unha páxina de inicio de sesión HTML nesa saída explica de inmediato unha capa baleira.

Un erro de PostgreSQL é unha boa noticia comparado cun tempo de espera. Proba que o destino respondeu, o que traslada o tícket do equipo de rede ao administrador de base de datos ou de GIS. Manter esa distinción no informe aforra unha viaxe.

Cando o proxecto se abre con capas baleiras

Dentro de QGIS, comprobe a orixe gardada da capa antes de volver introducir nada. As propiedades da capa mostran a cadea de conexión exacta que gardou o proxecto, e unha entrada de conexión duplicada cun host máis antigo é un resto habitual dunha rede de oficina anterior. Recargar o proxecto despois de corrixir unha conexión non sempre volve ler o provedor, así que elimine a capa e engádaa de novo desde a conexión corrixida.

Despois confirme que a configuración de autenticación é a ligada á capa, non só a presente na lista. Unha capa gardada con outra configuración de autenticación falla en silencio no panel do navegador mentres a proba psql independente pasa.

Cando a capa cargue, garde o proxecto con rutas relativas só para ficheiros e manteña as conexións de servizo nomeadas polo seu punto de conexión. A seguinte persoa que herde o proxecto poderá dicir que host esperaba unha capa rota sen abrir un tícket.