GeoServer와 PostGIS: 중요한 VPN 경로는 서버 쪽 경로입니다

QGIS에서 레이어를 열면 렌더링됩니다. 같은 VPN에 있는 동료는 같은 레이어에서 오류를 받습니다. 누군가는 VPN이 고장 났다고 결론짓고, 다음 한 시간은 데이터베이스를 옮기거나 둘 다 필요 없었던 포트를 여는 데 쓰입니다. 데스크톱에서 나가는 요청과 GeoServer가 PostGIS로 보내는 쿼리는 서로 다른 머신에서, 서로 다른 네트워크 이름 공간에서, 서로 다른 자격 증명으로 출발합니다. 이 두 경로를 분리하는 것이 진단의 대부분입니다.

두 연결, 두 출발점

QGIS  ->  client's permitted path (often the VPN)  ->  GeoServer listener
GeoServer -> server's permitted path  ->  PostGIS listener

두 번째 화살표는 첫 컴퓨터의 터널을 물려받지 않습니다. 컨테이너 안의 GeoServer는 호스트가 아니라 컨테이너의 네트워크 스택을 가지며, 브리지 네트워크의 컨테이너는 호스트가 닿지 못하는 데이터베이스에 닿을 수 있고 그 반대도 마찬가지입니다. 그래서 같은 사용자가 한 세션에서 성공하기도 하고 실패하기도 하는지는 응답이 캐시에서 왔는지 새 쿼리에서 왔는지에 따라 달라집니다.

실제로 실패한 단계를 찾으십시오

서비스 수준 거부, 데이터 저장소에 닿지 못하는 이미지 요청, 한 레이어의 권한 문제는 브라우저 탭에서는 비슷해 보이지만 서버 로그에서는 전혀 다릅니다. 구체적인 작업을 요청하고, 같은 타임스탬프의 서버 자체 이벤트를 읽으십시오.

curl -s -o /dev/null -w '%{http_code}\n' \
  "https://gis.example.com/geoserver/wms?service=WMS&version=1.3.0&request=GetCapabilities"

curl -s -o /tmp/tile.png -w '%{http_code} %{size_download}\n' \
  "https://gis.example.com/geoserver/wms?service=WMS&version=1.3.0&request=GetMap&layers=corp:parcels&bbox=-13650000,4500000,-13600000,4550000&width=256&height=256&srs=EPSG:3857&format=image/png"

두 번째 요청이 그럴듯한 이미지와 함께 200을 반환하면 데이터 저장소가 응답한 것입니다. 서비스 예외 문서와 함께 온 200은 응답하지 않았다는 뜻이며, 예외 문구는 보통 클라이언트가 아니라 저장소를 지목합니다.

데이터 저장소를 서버 쪽에서 읽으십시오

GeoServer의 PostGIS 참조 문서에는 저장소에 필요한 것, 즉 호스트, 포트, 데이터베이스, 자격 증명이 나열됩니다. 이 모두가 GeoServer가 여는 연결을 설명합니다. 그중 어느 것도 데스크톱 클라이언트의 로그인을 설명하지 않습니다. 이 네 필드를 서버의 네트워크 맥락에 대한 진술로 읽으면 «그쪽에서는 된다»는 부류의 티켓 전체가 다룰 수 있는 것이 됩니다.

그래서 localhost을 데이터 저장소에 넣는 것이 흔한 실수입니다. 그것은 GeoServer 프로세스 자체의 네트워크 맥락을 뜻합니다. GeoServer가 Docker에서 돌고 PostGIS가 호스트에서 돈다면, localhost은 컨테이너 안쪽을 가리키며 아무것도 찾지 못하고, 어떤 VPN 설정도 그것을 바꾸지 못합니다.

서버에서 경로, 리스너, 인증 정책을 그 순서로 확인하십시오. PostgreSQL의 호스트 기반 인증은 자기가 보는 출발지 주소와 대조하는데, 게이트웨이가 그 주소를 바꿀 수 있으므로 HBA 파일에 클라이언트 VPN 풀을 추가해도 서버 쪽 연결은 좀처럼 고쳐지지 않습니다. 서버가 할 방식, 즉 같은 호스트, 같은 포트, 같은 사용자로 시험하십시오. 그 시험이 통과하는데 GeoServer가 여전히 실패한다면 차이는 데이터베이스가 아니라 프로세스 맥락에 있습니다.

ip route get 10.20.5.11
ss -tnp | grep 5432
psql "host=10.20.5.11 dbname=gis user=geoserver" -c 'select 1'

풀과 캐시는 변경을 넘어 상태를 유지합니다

데이터 저장소의 연결 풀은 소켓을 열어 둡니다. 풀이 만들어진 한 시간 뒤에 올라온 터널이 반드시 풀에 새 경로를 주지는 않으며, 유휴 연결은 검증이나 타임아웃이 닫을 때까지 죽은 경로에 머물 수 있습니다. 복구를 가정하지 말고 설치된 저장소의 검증 설정을 확인하며, 어느 레이어가 실패했는지 알기 전에 서비스 전체를 재시작하고 싶은 유혹도 피하십시오.

타일 캐시는 그 문제의 거울상을 만들며, 데이터베이스 연결이 끊긴 훨씬 뒤에도 올바르게 보이는 지도를 제공할 수 있습니다. «도움이 되는지 보자»며 캐시를 비우면 어느 경로가 살아 있었는지 알려 줄 유일한 증거를 없애는 셈입니다.

두 출발점을 모두 밝혀 넘기십시오

빠른 수정을 얻는 설명은 GeoServer에 닿은 클라이언트 요청과 GeoServer가 끝내지 못한 백엔드 작업, 이 두 가지를 밝힙니다. 둘 다 있으면 올바른 담당자가 실패한 경로를 고칠 수 있습니다. 앞의 것만 있으면 자연스러운 수정은 데이터베이스를 공개하는 것이고, 그것은 더 나쁜 문제를 만들어 티켓을 닫을 뿐입니다.

레이어, 응답 코드, 서버 쪽 예외, 그리고 그것을 만든 컨테이너나 호스트를 적으십시오. 네 줄이면 되고, 모호함은 완전히 사라집니다.