QGIS PostGIS SSH ٹنل: TLS کے لیے سرور کا نام رکھیں

ٹنل اوپر آتا ہے، QGIS جڑتا ہے، اور لاگ اِن ڈیٹا بیس ہوسٹ کے بجائے 127.0.0.1 کا نام لینے والی سرٹیفکیٹ خرابی کے ساتھ مر جاتا ہے۔ اگلا دلکش قدم sslmode کو ڈھیلا کرنا ہے، جو جانچ کو خاموش کر دیتا ہے اور وہی شناخت کی ضمانت پھینک دیتا ہے جو آپ شروع ہی سے چاہتے تھے۔ اصل مسئلہ یہ ہے کہ مقامی پورٹ اور سرور کا نام ایک ہی فیلڈ میں محفوظ کیے جاتے ہیں۔ libpq سروس اندراج انہیں الگ کرتا ہے، اس لیے ساکٹ فارورڈ شدہ پورٹ پر جاتا ہے جبکہ TLS اب بھی سرٹیفکیٹ پر چھپا نام جانچتا ہے۔

کلائنٹ کیا سمجھتا ہے کہ وہ کس سے جڑ رہا ہے

sslmode=verify-full کے تحت libpq سرور کی پیش کردہ سرٹیفکیٹ کا موازنہ مطلوبہ ہوسٹ نام سے کرتا ہے۔ جب وہ نام loopback پتہ ہو، موازنہ ناکام ہو جاتا ہے اگرچہ سرٹیفکیٹ اصل ڈیٹا بیس ہوسٹ کے لیے درست ہو۔ SSH فارورڈ بدلتا ہے کہ کون سا ساکٹ بائٹس ڈھوتا ہے، وہ شناخت نہیں جس کی کلائنٹ کو توقع کرنی چاہیے۔ یہ دونوں تصورات الگ ہوتے ہی خرابی TLS نقص جیسی نہیں رہتی۔

فارورڈ اجازت بھی نہیں ہے۔ PostgreSQL SSH سرور کے بنائے گئے کنکشن پر اب بھی اپنے قواعد لاگو کرتا ہے، اس لیے کچھ بھی بدلنے سے پہلے نقل و حمل کی تہہ اور ڈیٹا بیس کی تہہ الگ رکھیں۔

فارورڈ کو صرف loopback سے باندھیں

سننے والا QGIS مشین ہی پر ہونا چاہیے، کہیں اور نہیں۔ 127.0.0.1 کا واضح ذکر اسے دوسرے انٹرفیس سے دور رکھتا ہے، جبکہ بائنڈ پتہ چھوڑ دینے سے SSH کلائنٹ کی گیٹ وے ترتیبات کے مطابق پورٹ باہر کھل سکتا ہے۔

ssh -N -L 127.0.0.1:15432:127.0.0.1:5432 [email protected]

دوسرے کولن کے بعد کی منزل SSH سرور کی طرف سے حل ہوتی ہے، اس لیے یہ مثال فرض کرتی ہے کہ PostgreSQL اسی ہوسٹ پر ہے جس پر sshd ہے؛ دوسری مشین پر ڈیٹا بیس کو وہ پتہ اور اس کی اجازتیں درکار ہیں۔ سیشن -N کے ساتھ شروع کریں تاکہ کوئی شیل نہ کھلے، ہوسٹ کی کی جانچ کو ہاتھ نہ لگائیں، اور QGIS کو قصوروار ٹھہرانے سے پہلے تصدیق کریں کہ سننے والا ظاہر ہوتا ہے۔ اگر پورٹ پہلے سے زیرِ استعمال ہو تو فارورڈ کوئری کے وقت نہیں بلکہ آغاز ہی میں ناکام ہوتا ہے۔

نام اور ساکٹ کو ایک ہی سروس اندراج میں رکھیں

سروس فائل اسی کنکشن کو جانچ کا نام اور الگ ساکٹ منزل ڈھونے دیتی ہے۔ اندراج وہاں محفوظ کریں جہاں libpq سروسز تلاش کرتا ہے، یا PGSERVICEFILE کو اس کی طرف اشارہ کریں۔

[gis-via-ssh]
host=db.geo.example
hostaddr=127.0.0.1
port=15432
dbname=gisdb
user=gis_reader
sslmode=verify-full
gssencmode=disable
sslrootcert=/path/to/approved-root.crt

یہاں host سرٹیفکیٹ جانچ کے لیے استعمال ہونے والی شناخت رکھتا ہے جبکہ hostaddr پیکٹ فارورڈ شدہ loopback پورٹ پر بھیجتا ہے، اور یہ ترتیب کام کرے اس کے لیے دونوں ضروری ہیں۔ gssencmode=disable ان بلڈز میں اہم ہے جو ورنہ پہلے GSSAPI انکرپشن پر بات چیت کرتے، کیونکہ وہ راستہ ابھی مقرر کردہ TLS ترتیبات کو نظر انداز کرتا ہے۔ QGIS کے PostgreSQL کنکشن ڈائیلاگ سے نام لے کر سروس کا حوالہ دیں اور پاس ورڈ مشترکہ فائل کے اندر نہیں بلکہ معمول کے پرامپٹ سے دیں۔ اوپر دیے گئے نام اور راستے پلیس ہولڈر ہیں؛ انہیں اپنی منظور شدہ قدروں سے بدلیں۔

ٹنل کے بعد PostgreSQL اب بھی کیا جانچتا ہے

سرور SSH ہوسٹ سے، اس ترتیب میں loopback سے، آنے والا کنکشن دیکھتا ہے اور اسے ترتیب سے ہوسٹ پر مبنی توثیق کے قواعد سے ملاتا ہے۔ آپ کے ڈیٹا بیس رول کو اب بھی توثیق کرنی ہوگی، اور SSH لاگ اِن بذاتِ خود کوئی ڈیٹا بیس شناخت نہیں دیتا۔ جو سرور مانتا ہے اس کی تصدیق کریں، جو کلائنٹ نے فرض کیا اس کی نہیں۔

psql "service=gis-via-ssh" -c "select inet_server_addr(), current_user"

کام مکمل ہونے پر فارورڈنگ سیشن بند کریں؛ مقامی اندراج پھر کام کرنا بند کر دیتا ہے اور کچھ اور تبدیل نہیں ہوتا۔ ڈیٹا بیس کا ایک راستہ پورے GIS کلائنٹ کے لیے VPN نہیں ہے، اور اسی کو VPN سمجھنا ہی اگلے کنکشن کی غلط تشخیص کی وجہ ہے۔