VPN کے ذریعے PostgreSQL: pg_hba کون سا ماخذ پتہ دیکھے گا

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

تین فیصلے جنہیں ملایا نہیں جانا چاہیے

سرور کہاں سنتا ہے یہ ایک فیصلہ ہے۔ کون سی ٹریفک اس پتے تک پہنچ سکتی ہے یہ دوسرا ہے، جو ہوسٹ فائر وال اور اس کے سامنے کی کوئی بھی نیٹ ورک حد لیتی ہے۔ کون سی ڈیٹا بیس شناخت کس ماخذ سے تصدیق کر سکتی ہے یہ تیسرا ہے، جو pg_hba.conf میں لیا جاتا ہے۔

ان میں سے ہر ایک کو مختلف جزو نافذ کرتا ہے، اور ہر ایک مختلف پیغام کے ساتھ ناکام ہوتا ہے۔ انہیں گفتگو میں ملانا ہی وہ طریقہ ہے جس سے لوگ فائر وال مسئلہ درست کرنے کے لیے HBA فائل میں ترمیم کرنے لگتے ہیں۔ انہیں ترتیب میں رکھیں: جو لسنر بندھا نہیں اس تک پہنچا نہیں جا سکتا، فلٹر شدہ پورٹ سے منسلک نہیں ہوا جا سکتا، اور HBA قاعدہ صرف یہ طے کرتا ہے کہ کنکشن موجود ہونے کے بعد کیا ہوتا ہے۔ جب کسی تبدیلی کا کوئی اثر نہ ہو، تو پہچانیں کہ آپ نے تین تہوں میں سے واقعی کون سی بدلی ہے۔

سرور کہاں سنتا ہے

مشین کو واقعی دیے گئے پتے پر بندھیں، انٹرفیس نام پر نہیں:

listen_addresses = '10.20.0.30'

ڈیٹا بیس اپنے سرنگ انٹرفیس کے بغیر VPN گیٹ وے کے پیچھے ہو سکتا ہے، اور اسی لیے پتہ ہی وہ درست چیز ہے جس کا نام دینا چاہیے۔ اس ترتیب کو بدلنے کے لیے مکمل دوبارہ آغاز درکار ہے؛ دوبارہ لوڈ کرنا کافی نہیں۔

پھر پورٹ، عام طور پر 5432، ہوسٹ پر اور اس کے سامنے کی ہر حد پر فلٹر کریں۔ نجی پتے پر بندھنا عوامی انکار کا ثبوت نہیں، کیونکہ پورٹ فارورڈنگ یا کلاؤڈ پتہ میپنگ اب بھی اس نجی لسنر تک پیکٹ پہنچا سکتی ہے۔

وہ پتہ جو HBA واقعی دیکھتا ہے

روٹ شدہ رسائی میں سرور ہر کلائنٹ کا اندرونی سرنگ پتہ دیکھتا ہے۔ ماخذ ترجمے میں یہ اس کے بجائے گیٹ وے کا ترجمہ شدہ پتہ دیکھتا ہے، اور ہر کلائنٹ اسی ایک قدر میں سمٹ جاتا ہے۔ اجازت دینے کے لیے سابقہ چننے سے پہلے سرور کے اپنے کنکشن ثبوتوں کے ذریعے ماخذ کا معائنہ کریں۔

پہلے سے TLS اور SCRAM استعمال کرنے والی تعیناتی کے لیے، جان بوجھ کر تنگ دور رسائی کی مثال ایسی دکھتی ہے:

hostssl appdb app_login 10.8.0.0/24 scram-sha-256
host all all 0.0.0.0/0 reject
host all all ::/0 reject

یہ بتائے گئے پول سے TLS کے ذریعے ایک کردار اور ایک ڈیٹا بیس کی اجازت دیتا ہے، پھر دیگر دور رس TCP رسائی کو مسترد کرتا ہے۔ یہ مکمل HBA فائل کا متبادل نہیں: مقامی انتظام، نقل اور کوئی بھی دوسری مجاز سروس رکھیں، اور تنگ قواعد کو وسیع اجازتوں سے پہلے رکھیں۔

جب ترجمہ عمل میں ہو، HBA کلائنٹس کو ان کے اصل پتوں سے الگ نہیں کر سکتا۔ نیٹ ورک داخلہ سخت رکھیں اور حقیقی ڈیٹا بیس اسناد کا مطالبہ کریں، اور کبھی trust تصدیق کو حقیقی اکاؤنٹ سے نہ بدلیں۔

پہلا مماثل جیتتا ہے، کوئی متبادل نہیں

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

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

HBA حوالہ ترتیب اور host اور hostssl ریکارڈز کے فرق دونوں کی وضاحت کرتا ہے، جو اس وقت اہم ہے جب قاعدے کا مقصد یہ ہو کہ کنکشن لازمی طور پر خفیہ ہو۔

دوبارہ لوڈ، دوبارہ آغاز اور مسترد شدہ صورت

HBA تبدیلیاں دوبارہ لوڈ سے لاگو ہوتی ہیں، اور pg_hba_file_rules منظر تجزیہ کی غلطیاں تلاش کرنے میں مدد کرتا ہے۔ وہ منظر فائل کے موجودہ مواد کی وضاحت کرتا ہے، نہ کہ چلتے سرور نے انہیں کامیابی سے لوڈ کیا یا نہیں، اس لیے صاف فہرست نئے قواعد کے فعال ہونے کا ثبوت نہیں۔

لسنر کی تبدیلیوں کے لیے اپنا دوبارہ آغاز درکار ہے، اور جب کسی تبدیلی کا کوئی اثر نظر نہ آئے تو دونوں کارروائیوں میں الجھنا آسان ہے۔

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