Ligar o QGIS ao PostGIS atrás de uma VPN: passo a passo
Aponte o QGIS ao PostGIS ou WMS atrás de uma VPN: separe o túnel do ponto final do serviço, mantenha TLS verify-full e teste cada fronteira por ordem.
O QGIS lê qualquer caminho que os seus fornecedores de dados consigam alcançar, por isso uma VPN ativa é apenas metade da configuração. O túnel dá ao ambiente de trabalho uma rota e uma política de resolução de nomes; o projeto continua a precisar do ponto final do serviço, do protocolo do fornecedor e das credenciais que o serviço aceitará. São três entradas distintas, e escrever o ouvinte público da VPN num campo de base de dados não é nenhuma delas. Este guia segue uma camada PostGIS desde o formulário do QGIS até uma linha devolvida e nomeia a fronteira que cada passo prova.
Comece pela camada, não pela VPN
Cada tipo de camada alcança um tipo diferente de ponto final. Uma camada PostGIS abre uma ligação PostgreSQL com anfitrião, porta, base de dados e função. Uma camada WMS ou WFS obtém um URL de serviço e depois analisa um documento de capacidades. Um shapefile numa partilha de rede só precisa de um caminho de ficheiro que o sistema operativo consiga abrir. Como são três mecanismos diferentes, um projeto vazio não lhe diz nada até saber qual está a depurar.
Pergunte ao operador de GIS pelo ponto final, pela porta, pela identidade exigida e pela política de acesso aplicável à sua conta. Mantenha o nome de anfitrião do serviço exatamente como foi emitido quando a implementação depende de DNS privado ou de verificações do nome no certificado. Reutilizar um endereço de anfitrião copiado da ligação guardada de outro utilizador é a forma mais rápida de chegar a uma máquina que responde mas guarda uma base de dados mais antiga.
As rotas, os recursos permitidos e a resolução de nomes pertencem a quem opera a VPN. Um formulário de origem de dados não pode instalar uma rota que o perfil do túnel nunca enviou, nem pode alargar uma política de gateway. Quando o anfitrião resolve e a porta responde, o lado de rede do problema está terminado.
Introduza o ponto final privado que o operador emitiu
O formulário PostgreSQL do QGIS reflete os campos que o libpq espera, por isso preencha-o pela mesma ordem que uma ligação de linha de comandos. Serviço e anfitrião recebem a máquina da base de dados, a porta recebe o ouvinte que o servidor abre de facto, e a base de dados recebe o catálogo concreto em vez do valor predefinido do servidor. Guarde a palavra-passe numa configuração de autenticação e não no ficheiro do projeto, para que um projeto partilhado não transporte credenciais.
Separe os dois nomes antes de escrever algo. O nome do gateway pertence ao cliente VPN e o nome da base de dados pertence ao QGIS, e raramente são o mesmo anfitrião.
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 dados estiver noutra máquina atrás do gateway, o nome no formulário tem de ser essa máquina. É o DNS privado através do túnel que faz o nome funcionar, e um projeto que só resolve enquanto está ligado comporta-se corretamente, não que faz cache mal.
Mantenha o modo TLS da base de dados separado do túnel
O SSL no nome de um produto VPN descreve o túnel, não a sessão da base de dados. O QGIS passa o modo SSL do PostgreSQL ao libpq, e esse modo controla se o cliente verifica o certificado do servidor e se confirma o nome de anfitrião contido nele. verify-fullfaz as duas coisas, por isso é o modo que vale a pena manter quando o certificado transporta o nome do serviço.
Baixar o modo para disable porque o túnel já está cifrado remove a verificação de que o servidor alcançado é o servidor pedido. Quando a verificação falha, a causa habitual é uma divergência de nome ou um certificado raiz em falta, e ambos se corrigem sem enfraquecer a ligação. Aponte sslrootcert para a AC que o operador publica e mantenha o nome de anfitrião no formulário idêntico ao nome no certificado.
Um túnel com rota privada e uma base de dados com certificado válido ainda podem falhar na função. As credenciais da aplicação são distintas das credenciais da VPN, e uma conta autenticada no gateway não tem direitos implícitos no PostgreSQL.
Teste cada fronteira por ordem e leia a primeira falha
Trabalhe do cliente para fora numa ordem fixa: resolução de nomes, alcance TCP, TLS, autenticação e depois a própria consulta. O primeiro passo que falha é o único que vale a pena relatar, e saltar à frente produz mensagens de erro de uma fronteira a que ainda não chegou. Quatro comandos cobrem os primeiros quatro passos.
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
Uma resposta vazia de getent é um problema de resolução, não um problema de base de dados. Um nc recusado ou expirado significa que falta uma rota ou uma regra de firewall, o que se corrige do lado do gateway. Um erro TLS de psql significa que o certificado ou o nome estão errados, enquanto password authentication failed significa que chegou ao PostgreSQL e o problema é a credencial. Para uma camada WMS, a chamada curl devolve o XML de capacidades que o QGIS analisaria, por isso uma página de início de sessão HTML nessa saída explica de imediato uma camada vazia.
Um erro PostgreSQL é boa notícia comparado com um tempo limite. Prova que o destino respondeu, o que transfere o ticket da equipa de rede para o administrador de base de dados ou de GIS. Manter essa distinção no relatório poupa uma volta.
Quando o projeto abre com camadas vazias
Dentro do QGIS, verifique a origem guardada da camada antes de voltar a introduzir algo. As propriedades da camada mostram a cadeia de ligação exata que o projeto guardou, e uma entrada de ligação duplicada com um anfitrião mais antigo é um resto comum de uma rede de escritório anterior. Recarregar o projeto depois de corrigir uma ligação nem sempre relê o fornecedor, por isso remova a camada e volte a adicioná-la a partir da ligação corrigida.
Depois confirme que a configuração de autenticação é a anexada à camada, não apenas a que existe na lista. Uma camada guardada com outra configuração de autenticação falha em silêncio no painel do navegador enquanto o teste psql autónomo passa.
Quando a camada carregar, guarde o projeto com caminhos relativos apenas para ficheiros e mantenha as ligações de serviço nomeadas pelo seu ponto final. A pessoa seguinte que herdar o projeto poderá então dizer que anfitrião esperava uma camada quebrada sem abrir um ticket.