เชื่อม QGIS กับ PostGIS หลัง VPN: ทีละขั้นตอน

QGIS อ่านเส้นทางใดก็ได้ที่ผู้ให้บริการข้อมูลเข้าถึงได้ ดังนั้น VPN ที่เชื่อมอยู่จึงเป็นเพียงครึ่งเดียวของการตั้งค่า อุโมงค์ให้เส้นทางและนโยบายการแก้ชื่อแก่เดสก์ท็อป แต่โปรเจกต์ยังต้องมีปลายทางของบริการ โพรโทคอลของผู้ให้บริการ และข้อมูลรับรองที่บริการจะยอมรับ สามอย่างนี้เป็นคนละช่อง และการพิมพ์ตัวรับฟังสาธารณะของ VPN ลงในช่องฐานข้อมูลก็ไม่ใช่สักอย่างในนั้น บทความนี้ติดตามชั้น PostGIS หนึ่งชั้นจากแบบฟอร์ม QGIS ไปจนถึงแถวที่ส่งกลับมา และระบุขอบเขตที่แต่ละขั้นตอนพิสูจน์

เริ่มจากชั้นข้อมูล ไม่ใช่จาก VPN

ชั้นข้อมูลแต่ละชนิดไปถึงปลายทางคนละแบบ ชั้น PostGIS เปิดการเชื่อมต่อ PostgreSQL ด้วยโฮสต์ พอร์ต ฐานข้อมูล และบทบาท ชั้น WMS หรือ WFS ดึง URL ของบริการแล้วจึงแยกเอกสารความสามารถ ส่วนไฟล์ shapefile บนพื้นที่แชร์เครือข่ายต้องการเพียงเส้นทางไฟล์ที่ระบบปฏิบัติการเปิดได้ เพราะเป็นกลไกสามอย่างที่ต่างกัน โปรเจกต์ว่างจึงไม่บอกอะไรเลยจนกว่าคุณจะรู้ว่ากำลังดีบักอันไหน

ถามผู้ดูแล GIS เรื่องปลายทาง พอร์ต ตัวตนที่ต้องใช้ และนโยบายการเข้าถึงที่ใช้กับบัญชีของคุณ รักษาชื่อโฮสต์ของบริการไว้ตามที่ออกให้เมื่อการติดตั้งขึ้นกับ DNS ส่วนตัวหรือการตรวจชื่อในใบรับรอง การนำที่อยู่โฮสต์ที่คัดลอกมาจากการเชื่อมต่อที่บันทึกไว้ของผู้อื่นกลับมาใช้เป็นวิธีที่เร็วที่สุดที่จะไปถึงเครื่องที่ตอบสนองแต่มีฐานข้อมูลเก่ากว่า

เส้นทาง ทรัพยากรที่อนุญาต และการแก้ชื่อเป็นของผู้ที่ดูแล VPN แบบฟอร์มแหล่งข้อมูลติดตั้งเส้นทางที่โปรไฟล์อุโมงค์ไม่เคยส่งไปไม่ได้ และขยายนโยบายของเกตเวย์ก็ไม่ได้ เมื่อโฮสต์แก้ชื่อได้และพอร์ตตอบสนอง ส่วนเครือข่ายของปัญหาก็จบ

กรอกปลายทางส่วนตัวที่ผู้ดูแลออกให้

แบบฟอร์ม PostgreSQL ใน QGIS สะท้อนช่องที่ 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 ของฐานข้อมูลออกจากอุโมงค์

SSL ในชื่อผลิตภัณฑ์ VPN อธิบายอุโมงค์ ไม่ใช่เซสชันฐานข้อมูล QGIS ส่งโหมด SSL ของ PostgreSQL ต่อไปยัง 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 ที่ถูกปฏิเสธหรือหมดเวลาหมายถึงขาดเส้นทางหรือกฎไฟร์วอลล์ ซึ่งเป็นการแก้ฝั่งเกตเวย์ psql ข้อผิดพลาด TLS หมายถึงใบรับรองหรือชื่อผิด ขณะที่ password authentication failed หมายถึงคุณไปถึง PostgreSQL แล้วและปัญหาเป็นข้อมูลรับรอง สำหรับชั้น WMS การเรียก curl ส่งคืน XML ความสามารถที่ QGIS จะแยกวิเคราะห์ ดังนั้นหน้าเข้าสู่ระบบ HTML ในผลลัพธ์นั้นจึงอธิบายชั้นว่างได้ทันที

ข้อผิดพลาด PostgreSQL เป็นข่าวดีเมื่อเทียบกับการหมดเวลา มันพิสูจน์ว่าปลายทางตอบสนอง ซึ่งย้ายตั๋วจากทีมเครือข่ายไปยังผู้ดูแลฐานข้อมูลหรือ GIS การเก็บความต่างนี้ไว้ในรายงานประหยัดการไปกลับหนึ่งรอบ

เมื่อโปรเจกต์เปิดขึ้นพร้อมชั้นข้อมูลว่าง

ใน QGIS ตรวจสอบแหล่งที่บันทึกไว้ของชั้นข้อมูลก่อนกรอกอะไรใหม่ คุณสมบัติของชั้นข้อมูลแสดงสตริงการเชื่อมต่อที่โปรเจกต์บันทึกไว้ และรายการเชื่อมต่อซ้ำที่มีโฮสต์เก่าก็เป็นเศษที่พบบ่อยจากเครือข่ายสำนักงานเดิม การโหลดโปรเจกต์ใหม่หลังแก้การเชื่อมต่อไม่ได้อ่านผู้ให้บริการใหม่เสมอไป จึงลบชั้นข้อมูลแล้วเพิ่มใหม่จากการเชื่อมต่อที่แก้แล้ว

จากนั้นยืนยันว่าการตั้งค่าการพิสูจน์ตัวตนคือชุดที่ผูกกับชั้นข้อมูล ไม่ใช่เพียงชุดที่มีในรายการ ชั้นข้อมูลที่บันทึกด้วยการตั้งค่าการพิสูจน์ตัวตนอื่นจะล้มเหลวเงียบ ๆ ในแผงเบราว์เซอร์ ขณะที่การทดสอบ psql แยกต่างหากผ่าน

เมื่อชั้นข้อมูลโหลดแล้ว บันทึกโปรเจกต์โดยใช้เส้นทางสัมพัทธ์เฉพาะไฟล์ และตั้งชื่อการเชื่อมต่อบริการตามปลายทางของมัน คนถัดไปที่รับช่วงโปรเจกต์จะบอกได้ว่าชั้นข้อมูลที่เสียคาดหวังโฮสต์ใดโดยไม่ต้องเปิดตั๋ว