VPN psql کو نہیں روکتا: آپ کا کلائنٹ کہیں اور ڈائل کرتا ہے
psql اور GUI کلائنٹ ایک ہی مشین سے مختلف اینڈ پوائنٹس پر ڈائل کر سکتے ہیں۔ VPN کو قصوروار ٹھہرانے سے پہلے ہوسٹ، ساکٹ، کردار اور TLS کا موازنہ کریں۔
دونوں کلائنٹ ایک ہی لیپ ٹاپ پر ہیں، ایک ہی ٹنل سے گزرتے ہیں، اور ان میں سے صرف ایک جڑتا ہے۔ یہ موازنہ اس بات کا ثبوت لگتا ہے کہ VPN انتخابی ہے، جبکہ زیادہ عام وضاحت یہ ہے کہ دونوں کلائنٹ مختلف منزلوں پر ڈائل کرتے ہیں۔ ایک GUI اپنا ہوسٹ، پورٹ، کردار اور TLS ترتیبات رکھتا ہے اور ضرورت پڑنے پر خاموشی سے SSH فارورڈ بناتا ہے، جبکہ psql آپ کے شیل کی پہلے سے مقرر کردہ libpq ڈیفالٹس سے کنکشن جوڑتا ہے۔ کام کرنے والے کنکشن کو دوبارہ بنانا GUI کی ترتیبات پڑھنے کا معاملہ ہے، ٹنل دوبارہ انسٹال کرنے کا نہیں۔
داستان: ایک کام کرنے والا کلائنٹ راستہ ثابت کرتا ہے
اگر GUI جڑتا ہے تو ٹنل ٹریفک لے جاتی ہے، اور GUI صرف یہی ثابت کرتا ہے۔ یہ نہیں بتاتا کہ psql کون سا پتہ حل کرتا ہے، کس کردار سے تصدیق کرتا ہے، یا وہ جو ساکٹ کھولتا ہے وہ کبھی مشین سے باہر جاتا ہے یا نہیں۔ راستہ مشترک ہے؛ پیرامیٹر نہیں۔
لوکل فارورڈ فرق کو مزید بڑھاتا ہے۔ GUI شاید SSH کے ذریعے فارورڈ کردہ پورٹ پر 127.0.0.1 سے جڑے، اور وہ سننے والا صرف GUI سیشن کے دوران موجود رہتا ہے۔ فارورڈ کے بغیر localhost کی طرف اشارہ کرنے والا psql ایسا مسترد کنکشن پاتا ہے جس کا VPN سے کوئی تعلق نہیں۔
وہ اینڈ پوائنٹ پڑھیں جو GUI واقعی استعمال کرتا ہے
کنکشن کی خصوصیات کھولیں اور چار اقدار نقل کریں: ہوسٹ، پورٹ، ڈیٹابیس اور کردار۔ پھر ٹنل ٹیب تلاش کریں، کیونکہ SSH فارورڈ ایک نجی پتہ کو لوکل پورٹ میں بدل دیتا ہے اور psql کو کیا بتانا ہے وہ بدل دیتا ہے۔
| Setting | What the GUI holds | What psql uses when the value is absent |
|---|---|---|
| Destination | A saved hostname, sometimes behind a forward | A local Unix socket, not the remote endpoint |
| Port | The direct port or a forwarded local port | 5432, or the port from a service file |
| Role and database | Stored per connection profile | Your operating-system user name |
| TLS identity | Its own CA bundle and verification mode | Whatever PGSSLMODE or the service file says |
| Startup files | Not read at all | Read unless -X is passed |
ہر قطار مختلف پرت پر ناکام ہوتی ہے، اور آپ کو ملنے والا پیغام اسی پرت کا نام لیتا ہے۔ محفوظ پروفائل کا دوستانہ نام psql میں چسپاں کرنے سے اوپر کی کوئی قدر نہیں جاتی، اور سروس کا نام ایسی فائل کے ذریعے حل ہوتا ہے جسے ٹرمینل شاید کبھی نہ پڑھے۔
libpq آپ کے شیل سے کیا ورثے میں لیتا ہے
psql، libpq کے اوپر ایک پتلا کلائنٹ ہے، اور libpq کسی اور چیز سے پہلے ماحول پڑھتا ہے۔ PGHOST, PGHOSTADDR, PGPORT, PGDATABASE, PGUSER, PGSERVICE اور PGSSLMODE جیسے متغیر میں سے ہر ایک کنکشن کا کوئی حصہ دوسری طرف موڑ سکتا ہے۔ یہ ٹائپ ہونے کے بجائے ورثے میں ملتے ہیں، اس لیے آپ کے چلائے گئے حکم میں کچھ بھی انہیں نہیں دکھاتا۔ برآمد شدہ PGSSLMODE بھی کمانڈ لائن پر ایک لفظ کہے بغیر بدل سکتا ہے کہ کلائنٹ کیا قبول کرتا ہے۔
ان متغیرات میں سے دو پہلے شک کے حقدار ہیں۔ PGHOSTADDR ایک عددی منزل فراہم کرتا ہے جو ناموں کے حل کو نظرانداز کرتا ہے جبکہ ہوسٹ کا نام اب بھی سرٹیفکیٹ کی شناخت طے کرتا ہے، اور PGSERVICE سروس فائل سے ہوسٹ، ڈیٹابیس اور TLS کے انتخاب کھینچ لیتا ہے۔ اسے ڈیبگ کرنے کے لیے پورا ماحول انڈیلنا بری عادت ہے، کیونکہ اس میں پاس ورڈ اور غیر متعلق ٹوکن ہو سکتے ہیں؛ اس کے بجائے وہ متغیر منتخب کریں جن کی آپ کو پرواہ ہے۔
host اور hostaddr دونوں چھوڑنے سے نیٹ ورک پتے کے بجائے Unix ڈومین ساکٹ منتخب ہوتا ہے۔ اس لیے -h کے بغیر psql کال مقامی طور پر کامیاب ہو سکتی ہے، یا ساکٹ خرابی سے ناکام ہو سکتی ہے، GUI کے استعمال کردہ راستے کو کبھی چھوئے بغیر۔
وہی پیرامیٹر ہاتھ سے بھیجیں
GUI کی اقدار ہاتھ میں ہوں تو انہیں واضح طور پر بھیجیں اور وہ اسٹارٹ اپ فائل چھوڑ دیں جو اوور رائیڈ شامل کر سکتی ہے۔ نیچے دی گئی کنکشن سٹرنگ مثال ہے: اینڈ پوائنٹ، پورٹ، ڈیٹابیس اور کردار کو ان اقدار سے بدلیں جنہیں آپ کے منتظم نے منظور کیا ہے، اور پہلے سے کام کرنے والی اعتماد ترتیب رکھیں۔
psql -X "host=db.internal.example port=6432 dbname=orders user=report_ro sslmode=verify-full connect_timeout=5"اس حکم میں تین تفصیلات دانستہ ہیں۔ -X psql کی اسٹارٹ اپ فائل کو دباتا ہے، اگرچہ libpq کے ماحول یا سروس کی تعریف کو نہیں دباتا۔ connect_timeout=5 خالی راستے کو ٹرمینل منٹوں تک لٹکانے سے روکتا ہے۔ sslmode=verify-full سرٹیفکیٹ اور ہوسٹ نام کی جانچیں آن رکھتا ہے، اور TLS خرابی ظاہر ہونے پر لوگ ٹھیک یہی حصہ بند کرتے ہیں۔
اگر منظور شدہ اینڈ پوائنٹ کسی pooler کے پیچھے ہے تو پورٹ 6432 اور پورٹ 5432 مختلف سرور شناختوں کے ذریعے اسی ڈیٹا تک پہنچ سکتے ہیں، اور تصدیق ڈیٹابیس کے نام پر نہیں بلکہ pooler کے نام پر ناکام ہو سکتی ہے۔ موڈ کمزور کرنے کے بجائے کنکشن سٹرنگ میں نام درست کریں۔
اگلا قدم خرابی کا پیغام منتخب کرے
ناکامی کا متن بتاتا ہے کہ کوشش کتنی دور گئی، اور یہ ٹنل کے بارے میں کسی بھی اندازے سے بہتر ہے۔ جو نام حل نہیں ہوتا وہ ساکٹ بننے سے پہلے ناکام ہوتا ہے، وقت کا ختم ہونا یعنی راستے یا فائر وال نے پیکٹ گرا دیے، انکار یعنی کسی چیز نے جواب دے کر انکار کیا، اور تصدیق کی خرابی یعنی نیٹ ورک پہلے ہی کام کر رہا تھا۔
psql -X -w "host=db.internal.example port=6432 dbname=orders user=report_ro sslmode=verify-full connect_timeout=5" -c '\conninfo'
env | grep -E '^PG'
psql --version\conninfo کے آؤٹ پٹ کا GUI کے زندہ سیشن سے موازنہ کریں: وہی ہوسٹ، وہی پورٹ، وہی کردار، وہی TLS حالت۔ جب یہ چاروں مل جائیں تو VPN کے پاس کہنے کو کچھ نہیں بچتا۔ جب تک یہ نہ ملیں، ٹنل میں ہر اضافی تبدیلی ایسے کنکشن کے بارے میں اندازہ ہے جو ٹرمینل نے کبھی نہیں بنایا۔