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 کال وہ صلاحیتوں کی XML واپس کرتی ہے جو QGIS تجزیہ کرتا، اس لیے اس آؤٹ پٹ میں HTML لاگ ان صفحہ خالی تہہ کی فوراً وضاحت کرتا ہے۔

وقت گزرنے کے مقابلے میں PostgreSQL خرابی اچھی خبر ہے۔ یہ ثابت کرتی ہے کہ منزل نے جواب دیا، جو ٹکٹ کو نیٹ ورک ٹیم سے ڈیٹا بیس یا GIS منتظم کی طرف منتقل کرتا ہے۔ رپورٹ میں یہ فرق رکھنا ایک چکر بچاتا ہے۔

جب منصوبہ خالی تہوں کے ساتھ کھلتا ہے

QGIS کے اندر، کچھ دوبارہ درج کرنے سے پہلے تہہ کا محفوظ ماخذ دیکھیں۔ تہہ کی خصوصیات وہی درست کنکشن سٹرنگ دکھاتی ہیں جو منصوبے نے محفوظ کی، اور پرانے میزبان والی دہری کنکشن اندراج پچھلے دفتری نیٹ ورک کی عام باقیات ہے۔ کنکشن درست کرنے کے بعد منصوبہ دوبارہ لوڈ کرنا ہمیشہ فراہم کنندہ کو دوبارہ نہیں پڑھتا، اس لیے تہہ ہٹائیں اور درست شدہ کنکشن سے دوبارہ شامل کریں۔

پھر تصدیق کریں کہ تصدیق کی تشکیل وہی ہے جو تہہ سے منسلک ہے، صرف فہرست میں موجود نہیں۔ مختلف تصدیق کی تشکیل کے ساتھ محفوظ تہہ براؤزر پینل میں خاموشی سے ناکام ہوتی ہے، جبکہ آزاد psql جانچ پاس ہوتی ہے۔

جب تہہ لوڈ ہو، منصوبہ کو صرف فائلوں کے لیے نسبتی راستوں کے ساتھ محفوظ کریں اور سروس کنکشنوں کو ان کے اینڈ پوائنٹ کے نام پر رکھیں۔ منصوبہ ورثے میں پانے والا اگلا شخص ٹکٹ کھولے بغیر بتا سکے گا کہ ٹوٹی تہہ کس میزبان کی توقع کر رہی تھی۔