Conectar QGIS con PostGIS detrás de una VPN: paso a paso

QGIS lee cualquier ruta que sus proveedores de datos puedan alcanzar, así que una VPN activa es solo la mitad de la configuración. El túnel le da al escritorio una ruta y una política de resolución de nombres; el proyecto todavía necesita el punto de conexión del servicio, el protocolo del proveedor y las credenciales que el servicio aceptará. Son tres entradas distintas, y escribir el oyente público de la VPN en un campo de base de datos no es ninguna de ellas. Este recorrido sigue una capa de PostGIS desde el formulario de QGIS hasta una fila devuelta y nombra la frontera que demuestra cada paso.

Empiece por la capa, no por la VPN

Cada tipo de capa llega a un tipo distinto de punto de conexión. Una capa de PostGIS abre una conexión PostgreSQL con un host, un puerto, una base de datos y un rol. Una capa WMS o WFS obtiene una URL de servicio y luego analiza un documento de capacidades. Un shapefile en un recurso compartido de red solo necesita una ruta de archivo que el sistema operativo pueda abrir. Como son tres mecanismos distintos, un proyecto vacío no le dice nada hasta que sabe cuál está depurando.

Pregunte al operador de GIS por el punto de conexión, el puerto, la identidad requerida y la política de acceso que se aplica a su cuenta. Mantenga el nombre de host del servicio exactamente como se emitió cuando el despliegue depende de DNS privado o de comprobaciones de nombre en el certificado. Reutilizar una dirección de host copiada de la conexión guardada de otro usuario es la forma más rápida de llegar a una máquina que responde pero tiene una base de datos más antigua.

Las rutas, los recursos permitidos y la resolución de nombres pertenecen a quien administra la VPN. Un formulario de origen de datos no puede instalar una ruta que el perfil del túnel nunca envió, ni puede ampliar una política de puerta de enlace. Cuando el host resuelve y el puerto responde, el lado de red del problema ha terminado.

Introduzca el punto de conexión privado que emitió el operador

El formulario PostgreSQL de QGIS refleja los campos que espera libpq, así que complételo en el mismo orden que seguiría una conexión de línea de comandos. Servicio y host toman la máquina de la base de datos, el puerto toma el oyente que el servidor abre realmente, y la base de datos toma el catálogo concreto en lugar del valor predeterminado del servidor. Guarde la contraseña en una configuración de autenticación y no en el archivo del proyecto, para que un proyecto compartido no lleve una credencial.

Separe los dos nombres antes de escribir nada. El nombre de la puerta de enlace pertenece al cliente VPN y el nombre de la base de datos pertenece a QGIS, y rara vez son el mismo 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

Si la base de datos está en otra máquina detrás de la puerta de enlace, el nombre del formulario debe ser esa máquina. El DNS privado a través del túnel es lo que hace funcionar el nombre, y un proyecto que solo resuelve mientras está conectado se comporta correctamente, no que cachee mal.

Mantenga el modo TLS de la base de datos separado del túnel

El SSL del nombre de un producto VPN describe el túnel, no la sesión de la base de datos. QGIS pasa el modo SSL de PostgreSQL a libpq, y ese modo controla si el cliente verifica el certificado del servidor y si comprueba el nombre de host que contiene. verify-fullhace ambas cosas, por eso es el modo que vale la pena mantener cuando el certificado lleva el nombre del servicio.

Bajar el modo a disable porque el túnel ya está cifrado elimina la comprobación de que el servidor al que llegó es el servidor que pidió. Cuando la verificación falla, la causa habitual es un desajuste de nombre o un certificado raíz ausente, y ambos se pueden corregir sin debilitar la conexión. Apunte sslrootcert al CA que publica el operador y mantenga el nombre de host del formulario idéntico al nombre del certificado.

Un túnel con una ruta privada y una base de datos con un certificado válido todavía pueden fallar por el rol. Las credenciales de la aplicación son independientes de las credenciales de la VPN, y una cuenta que se autentica en la puerta de enlace no tiene derechos implícitos en PostgreSQL.

Pruebe cada frontera en orden y lea el primer fallo

Trabaje desde el cliente hacia fuera en un orden fijo: resolución de nombres, alcance TCP, TLS, autenticación y luego la propia consulta. El primer paso que falla es el único que vale la pena reportar, y saltar hacia delante produce mensajes de error de una frontera a la que aún no ha llegado. Cuatro comandos cubren los cuatro primeros 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

Una respuesta vacía de getent es un problema de resolución, no un problema de base de datos. Un nc rechazado o agotado significa que falta una ruta o una regla de cortafuegos, lo que se corrige del lado de la puerta de enlace. Un error TLS de psql significa que el certificado o el nombre son incorrectos, mientras que password authentication failed significa que llegó a PostgreSQL y el problema es la credencial. Para una capa WMS, la llamada curl devuelve el XML de capacidades que QGIS analizaría, así que una página de inicio de sesión HTML en esa salida explica de inmediato una capa vacía.

Un error de PostgreSQL es una buena noticia comparado con un tiempo de espera. Demuestra que el destino respondió, lo que traslada el ticket del equipo de red al administrador de base de datos o de GIS. Mantener esa distinción en el informe ahorra un viaje.

Cuando el proyecto se abre con capas vacías

Dentro de QGIS, compruebe el origen guardado de la capa antes de volver a introducir nada. Las propiedades de la capa muestran la cadena de conexión exacta que guardó el proyecto, y una entrada de conexión duplicada con un host más antiguo es un resto habitual de una red de oficina anterior. Recargar el proyecto tras corregir una conexión no siempre vuelve a leer el proveedor, así que elimine la capa y agréguela de nuevo desde la conexión corregida.

Después confirme que la configuración de autenticación es la adjunta a la capa, no solo la presente en la lista. Una capa guardada con otra configuración de autenticación falla en silencio en el panel del navegador mientras la prueba psql independiente pasa.

Cuando la capa cargue, guarde el proyecto con rutas relativas solo para archivos y mantenga las conexiones de servicio nombradas por su punto de conexión. La siguiente persona que herede el proyecto podrá decir qué host esperaba una capa rota sin abrir un ticket.