ربط 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 أو انتهاء مهلته يعني أن المسار أو قاعدة جدار حماية مفقودة، وهو إصلاح من جانب البوابة. خطأ TLS من psql يعني أن الشهادة أو الاسم خاطئ، بينما password authentication failed يعني أنك وصلت إلى PostgreSQL والمشكلة في بيانات الاعتماد. أما طبقة WMS، فإن استدعاء curl يعيد XML القدرات الذي كان QGIS سيحلّله، لذا صفحة تسجيل دخول HTML في ذلك الناتج تفسّر طبقة فارغة فورًا.

خطأ PostgreSQL خبر جيد مقارنة بمهلة. إنه يثبت أن الوجهة استجابت، وهذا ينقل التذكرة من فريق الشبكة إلى مسؤول قاعدة البيانات أو GIS. والحفاظ على هذا التمييز في التقرير يوفر رحلة ذهاب وإياب.

عندما يُفتح المشروع بطبقات فارغة

داخل QGIS، تحقّق من المصدر المحفوظ للطبقة قبل إعادة إدخال أي شيء. تُظهر خصائص الطبقة سلسلة الاتصال الدقيقة التي حفظها المشروع، ووجود إدخال اتصال مكرر بمضيف أقدم من بقايا شبكة مكتب سابقة شائعة. وإعادة تحميل المشروع بعد إصلاح اتصال لا تعيد قراءة الموفّر دائمًا، لذا احذف الطبقة وأضفها مرة أخرى من الاتصال المصحّح.

ثم تأكد أن إعداد المصادقة هو المرتبط بالطبقة، لا مجرد موجود في القائمة. الطبقة المحفوظة بإعداد مصادقة مختلف تفشل بصمت في لوحة المتصفح بينما ينجح اختبار psql المستقل.

عند تحميل الطبقة، احفظ المشروع بمسارات نسبية للملفات فقط، وأبقِ اتصالات الخدمة مسمّاة وفق نقطة نهايتها. حينها يستطيع من يرث المشروع أن يعرف أي مضيف توقّعته طبقة معطلة دون فتح تذكرة.