VPN 뒤에서 QGIS를 PostGIS에 연결하기: 단계별 안내

QGIS는 데이터 공급자가 도달할 수 있는 모든 경로를 읽으므로 연결된 VPN은 설정의 절반에 불과합니다. 터널은 데스크톱에 경로와 이름 해석 정책을 주지만, 프로젝트에는 여전히 서비스 엔드포인트와 공급자 프로토콜, 그리고 서비스가 받아들일 자격 증명이 필요합니다. 이 셋은 서로 다른 항목이며, VPN의 공용 리스너를 데이터베이스 필드에 입력하는 것은 어느 것도 아닙니다. 이 글은 QGIS 양식에서 반환된 행까지 PostGIS 레이어 하나를 따라가며 각 단계가 증명하는 경계를 짚습니다.

VPN이 아니라 레이어에서 시작하세요

레이어 유형마다 도달하는 엔드포인트의 종류가 다릅니다. PostGIS 레이어는 호스트, 포트, 데이터베이스, 역할로 PostgreSQL 연결을 엽니다. WMS나 WFS 레이어는 서비스 URL을 가져온 뒤 기능 문서를 해석합니다. 네트워크 공유의 shapefile은 운영 체제가 열 수 있는 파일 경로만 있으면 됩니다. 이 셋은 서로 다른 메커니즘이므로, 빈 프로젝트는 어느 것을 디버깅하는지 알기 전까지 아무것도 알려주지 않습니다.

GIS 운영자에게 엔드포인트, 포트, 필요한 신원, 계정에 적용되는 접근 정책을 물으세요. 배포가 사설 DNS나 인증서의 이름 검사에 의존한다면 서비스 호스트 이름을 발급된 그대로 유지하세요. 다른 사용자의 저장된 연결에서 복사한 호스트 주소를 재사용하는 것은 응답은 하지만 오래된 데이터베이스를 가진 머신에 도달하는 가장 빠른 길입니다.

경로, 허용된 리소스, 이름 해석은 VPN을 운영하는 사람의 몫입니다. 데이터 원본 양식은 터널 프로필이 한 번도 밀어 넣지 않은 경로를 설치할 수 없고, 게이트웨이 정책을 넓힐 수도 없습니다. 호스트가 해석되고 포트가 응답하면 문제의 네트워크 측은 끝난 것입니다.

운영자가 발급한 사설 엔드포인트를 입력하세요

QGIS의 PostgreSQL 양식은 libpq가 기대하는 필드를 그대로 반영하므로 명령줄 연결과 같은 순서로 채우세요. 서비스와 호스트는 데이터베이스 머신을, 포트는 서버가 실제로 여는 리스너를, 데이터베이스는 서버 기본값 대신 특정 카탈로그를 받습니다. 암호는 프로젝트 파일이 아니라 인증 구성에 저장해, 공유 프로젝트가 자격 증명을 지니지 않게 하세요.

무언가를 입력하기 전에 두 이름을 분리하세요. 게이트웨이 이름은 VPN 클라이언트에, 데이터베이스 이름은 QGIS에 속하며 둘은 좀처럼 같은 호스트가 아닙니다.

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

데이터베이스가 게이트웨이 뒤의 다른 머신에 있다면 양식의 이름은 그 머신이어야 합니다. 터널을 통한 사설 DNS가 이름을 동작하게 하며, 연결된 동안에만 해석되는 프로젝트는 캐시를 잘못하는 것이 아니라 올바로 동작하는 것입니다.

데이터베이스 TLS 모드를 터널과 분리해 두세요

VPN 제품 이름의 SSL은 데이터베이스 세션이 아니라 터널을 뜻합니다. QGIS는 PostgreSQL SSL 모드를 libpq로 넘기며, 그 모드는 클라이언트가 서버 인증서를 검증하는지와 그 안의 호스트 이름을 확인하는지를 제어합니다. verify-full둘 다 하므로, 인증서가 서비스 이름을 담을 때 유지할 만한 모드입니다.

터널이 이미 암호화되어 있다는 이유로 모드를 disable 로 낮추면, 도달한 서버가 요청한 서버인지 확인하는 절차가 사라집니다. 검증이 실패할 때 흔한 원인은 이름 불일치나 루트 인증서 누락이며 둘 다 연결을 약화하지 않고 고칠 수 있습니다. sslrootcert 를 운영자가 공개한 CA로 지정하고 양식의 호스트 이름을 인증서의 이름과 같게 유지하세요.

사설 경로가 있는 터널과 유효한 인증서가 있는 데이터베이스라도 역할에서 실패할 수 있습니다. 애플리케이션 자격 증명은 VPN 자격 증명과 별개이며, 게이트웨이에서 인증된 계정이 PostgreSQL에서 암묵적 권한을 갖지는 않습니다.

각 경계를 순서대로 시험하고 첫 실패를 읽으세요

클라이언트에서 바깥으로 고정된 순서로 진행하세요: 이름 해석, TCP 도달성, TLS, 인증, 그다음 질의 자체입니다. 처음 실패한 단계만 보고할 가치가 있으며, 건너뛰면 아직 도달하지 않은 경계에서 나온 오류 메시지가 나옵니다. 네 개의 명령이 처음 네 단계를 덮습니다.

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

getent 의 빈 응답은 이름 해석 문제이지 데이터베이스 문제가 아닙니다. 거부되거나 시간 초과된 nc 는 경로나 firewall 규칙이 빠졌다는 뜻이며 게이트웨이 측 수정입니다. psql 의 TLS 오류는 인증서나 이름이 틀렸다는 뜻이고, password authentication failed 는 PostgreSQL에 도달했고 자격 증명이 문제라는 뜻입니다. WMS 레이어의 경우 curl 호출은 QGIS가 해석할 기능 XML을 반환하므로, 그 출력의 HTML 로그인 페이지는 빈 레이어를 즉시 설명합니다.

PostgreSQL 오류는 시간 초과에 비하면 좋은 소식입니다. 목적지가 응답했다는 증거이며, 이는 티켓을 네트워크 팀에서 데이터베이스나 GIS 관리자에게 옮깁니다. 보고서에 이 구분을 남기면 왕복 한 번을 아낍니다.

프로젝트가 빈 레이어로 열릴 때

QGIS 안에서 무엇이든 다시 입력하기 전에 레이어에 저장된 원본을 확인하세요. 레이어 속성은 프로젝트가 저장한 정확한 연결 문자열을 보여 주며, 더 오래된 호스트가 있는 중복 연결 항목은 이전 사무실 네트워크의 흔한 잔재입니다. 연결을 고친 뒤 프로젝트를 다시 불러와도 공급자를 항상 다시 읽지는 않으므로 레이어를 제거하고 수정된 연결에서 다시 추가하세요.

그다음 인증 구성이 목록에 있을 뿐 아니라 레이어에 연결된 것인지 확인하세요. 다른 인증 구성으로 저장된 레이어는 브라우저 패널에서 조용히 실패하는 반면 독립 psql 시험은 통과합니다.

레이어가 로드되면 파일에만 상대 경로를 쓰도록 프로젝트를 저장하고 서비스 연결은 엔드포인트 이름으로 유지하세요. 프로젝트를 이어받는 다음 사람은 티켓을 열지 않고도 망가진 레이어가 어느 호스트를 기대했는지 알 수 있습니다.