Conectarea QGIS la PostGIS în spatele unui VPN: pas cu pas
Îndreptați QGIS către PostGIS sau WMS în spatele unui VPN: separați tunelul de punctul final al serviciului, păstrați TLS verify-full și testați fiecare graniță în ordine.
QGIS citește orice cale pe care furnizorii săi de date o pot atinge, așa că un VPN activ este doar jumătate din configurare. Tunelul îi dă desktopului o rută și o politică de rezolvare a numelor; proiectul are în continuare nevoie de punctul final al serviciului, de protocolul furnizorului și de acreditările pe care serviciul le va accepta. Acestea sunt trei câmpuri separate, iar tastarea ascultătorului public al VPN într-un câmp de bază de date nu este niciunul dintre ele. Acest ghid urmărește un strat PostGIS de la formularul QGIS până la un rând returnat și numește granița pe care o dovedește fiecare pas.
Începeți cu stratul, nu cu VPN-ul
Fiecare tip de strat ajunge la un alt fel de punct final. Un strat PostGIS deschide o conexiune PostgreSQL cu gazdă, port, bază de date și rol. Un strat WMS sau WFS aduce un URL de serviciu și apoi analizează un document de capabilități. Un shapefile pe o partajare de rețea are nevoie doar de o cale de fișier pe care sistemul de operare o poate deschide. Deoarece sunt trei mecanisme diferite, un proiect gol nu vă spune nimic până nu știți pe care îl depanați.
Întrebați operatorul GIS despre punctul final, port, identitatea necesară și politica de acces aplicabilă contului dumneavoastră. Păstrați numele de gazdă al serviciului exact așa cum a fost emis atunci când implementarea depinde de DNS privat sau de verificări ale numelui din certificat. Reutilizarea unei adrese de gazdă copiate din conexiunea salvată a altui utilizator este cea mai rapidă cale către o mașină care răspunde dar păstrează o bază de date mai veche.
Rutele, resursele permise și rezolvarea numelor aparțin celui care administrează VPN-ul. Un formular de sursă de date nu poate instala o rută pe care profilul tunelului nu a trimis-o niciodată și nu poate lărgi o politică de gateway. Când gazda se rezolvă și portul răspunde, partea de rețea a problemei s-a terminat.
Introduceți punctul final privat emis de operator
Formularul PostgreSQL din QGIS oglindește câmpurile pe care le așteaptă libpq, așa că completați-l în aceeași ordine ca o conexiune din linia de comandă. Serviciu și gazdă iau mașina bazei de date, portul ia ascultătorul pe care serverul îl deschide efectiv, iar baza de date ia catalogul concret în loc de valoarea implicită a serverului. Păstrați parola într-o configurație de autentificare, nu în fișierul proiectului, astfel încât un proiect partajat să nu transporte acreditări.
Separați cele două nume înainte de a tasta ceva. Numele gateway-ului aparține clientului VPN, iar numele bazei de date aparține QGIS, și rareori sunt aceeași gazdă.
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
Dacă baza de date se află pe altă mașină în spatele gateway-ului, numele din formular trebuie să fie acea mașină. DNS-ul privat prin tunel este ceea ce face numele să funcționeze, iar un proiect care se rezolvă doar cât timp sunteți conectat se comportă corect, nu că face cache prost.
Păstrați modul TLS al bazei de date separat de tunel
SSL din numele unui produs VPN descrie tunelul, nu sesiunea bazei de date. QGIS transmite modul SSL PostgreSQL către libpq, iar acel mod controlează dacă clientul verifică certificatul serverului și dacă verifică numele de gazdă din el. verify-fullface ambele, de aceea este modul care merită păstrat când certificatul poartă numele serviciului.
Coborârea modului la disable pentru că tunelul este deja criptat elimină verificarea că serverul atins este serverul cerut. Când verificarea eșuează, cauza obișnuită este o nepotrivire de nume sau un certificat rădăcină lipsă, iar ambele se pot remedia fără a slăbi conexiunea. Îndreptați sslrootcert către CA pe care operatorul îl publică și păstrați numele de gazdă din formular identic cu numele din certificat.
Un tunel cu rută privată și o bază de date cu certificat valid pot eșua în continuare la rol. Acreditările aplicației sunt separate de cele ale VPN-ului, iar un cont care se autentifică la gateway nu are drepturi implicite în PostgreSQL.
Testați fiecare graniță în ordine și citiți primul eșec
Lucrați de la client spre exterior într-o ordine fixă: rezolvarea numelor, accesibilitatea TCP, TLS, autentificarea și apoi interogarea propriu-zisă. Primul pas care eșuează este singurul care merită raportat, iar sărirea înainte produce mesaje de eroare de la o graniță la care nu ați ajuns încă. Patru comenzi acoperă primele patru pași.
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
Un răspuns gol de la getent este o problemă de rezolvare, nu o problemă de bază de date. Un nc refuzat sau expirat înseamnă că lipsește o rută sau o regulă de firewall, ceea ce este o corectare pe partea gateway-ului. O eroare TLS de la psql înseamnă că certificatul sau numele sunt greșite, în timp ce password authentication failed înseamnă că ați ajuns la PostgreSQL și problema este acreditarea. Pentru un strat WMS, apelul curl returnează XML-ul de capabilități pe care QGIS l-ar analiza, așa că o pagină de autentificare HTML în acea ieșire explică imediat un strat gol.
O eroare PostgreSQL este o veste bună în comparație cu un timeout. Dovedește că destinația a răspuns, ceea ce mută tichetul de la echipa de rețea la administratorul bazei de date sau GIS. Păstrarea acestei distincții în raport economisește o rundă.
Când proiectul se deschide cu straturi goale
În QGIS, verificați sursa salvată a stratului înainte de a reintroduce ceva. Proprietățile stratului arată șirul de conexiune exact pe care proiectul l-a salvat, iar o intrare de conexiune duplicată cu o gazdă mai veche este o rămășiță obișnuită dintr-o rețea de birou anterioară. Reîncărcarea proiectului după corectarea unei conexiuni nu recitește întotdeauna furnizorul, așa că eliminați stratul și adăugați-l din nou din conexiunea corectată.
Apoi confirmați că configurația de autentificare este cea atașată stratului, nu doar cea prezentă în listă. Un strat salvat cu altă configurație de autentificare eșuează în tăcere în panoul browserului, în timp ce testul psql independent trece.
Când stratul se încarcă, salvați proiectul cu căi relative doar pentru fișiere și păstrați conexiunile de serviciu denumite după punctul lor final. Următoarea persoană care moștenește proiectul poate spune atunci ce gazdă aștepta un strat stricat fără a deschide un tichet.