دفتر کے سرور پر ایپ localhost پر MySQL سے جڑتی ہے، آپ وہ ہوسٹ نام ڈیسک ٹاپ کلائنٹ میں کاپی کرتے ہیں، اور کنکشن یا تو ناکام ہوتا ہے یا کوئی دوسرا ڈیٹابیس کھول دیتا ہے۔ VPN نے لفظ کے معنی میں کچھ نہیں بدلا: localhost اب بھی اسی مشین کی طرف اشارہ کرتا ہے جس پر کلائنٹ چلتا ہے۔ VPN نے پیکٹ ہلائے، انٹرفیس نہیں۔ کسی بھی راستے کو چھونے سے پہلے طے کریں کہ لیپ ٹاپ کو کس اختتامی نقطے تک پہنچنا ہے۔

مرحلہ 1: طے کریں کہ لیپ ٹاپ کو کس اختتامی نقطے تک پہنچنا ہے

دونوں ڈیزائن جائز ہیں اور مختلف سوالات کا جواب دیتے ہیں۔ براہ راست رسائی کا مطلب ہے کہ ڈیٹابیس اس نجی پتے پر سنتا ہے جہاں سرنگ پہنچتی ہے، اور لیپ ٹاپ اس پتے سے جڑتا ہے۔ فارورڈ شدہ رسائی کا مطلب ہے کہ ڈیٹابیس loopback پر رہتا ہے اور SSH سیشن پورٹ کو آپ کی مشین تک لے جاتا ہے۔ ایک جان بوجھ کر چنیں، کیونکہ دونوں ملانے سے ایسا کنکشن بنتا ہے جو غلط وجہ سے کام کرتا ہے۔

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

مرحلہ 2: پورٹ فارورڈ کریں صرف اس وقت جب سامع مقامی رہے

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

ssh -N -o ExitOnForwardFailure=yes -L 127.0.0.1:13306:127.0.0.1:3306 [email protected]
ss -ltn 'sport = :13306'

اگر SSH ڈیٹابیس ہوسٹ کی بجائے جمپ ہوسٹ پر اترے، تو دائیں طرف کا loopback جمپ ہوسٹ کی طرف اشارہ کرتا ہے، اور ہدف کو اس پتے پر بدلنا ہوگا جہاں وہ ہوسٹ پہنچتا ہے۔ ExitOnForwardFailure فارورڈ قائم کرنے کی ناکامی پکڑتا ہے، مگر یہ ثابت نہیں کرتا کہ ہدف تک بعد کے کنکشن کامیاب ہوتے ہیں۔ ہوسٹ کی کی جانچ آن رکھیں، اور فارورڈنگ پورٹ کو تمام انٹرفیس سے باندھ کر اپنے پورے LAN کو نہ دیں۔

رکیں اگر ڈیٹابیس کو صرف loopback پر رہنا ہے اور آپ SSH استعمال نہیں کر سکتے۔ تب براہ راست رسائی غلط ڈیزائن ہے، زبردستی مسلط کرنے والی کنفیگریشن نہیں۔

مرحلہ 3: کلائنٹ کو TCP پر مجبور کریں

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

mysql --protocol=TCP --host=127.0.0.1 --port=13306 --user=DB_USER --password

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

رکیں اگر اوزار کو TCP پر مجبور نہیں کیا جا سکتا۔ تب دوسرا کلائنٹ استعمال کریں، یا نجی سامع تک براہ راست رسائی استعمال کریں۔

مرحلہ 4: ثابت کریں کہ آپ واقعی کس اختتامی نقطے تک پہنچے

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

mysql --protocol=TCP -h 127.0.0.1 -P 13306 -u DB_USER -p -e "SELECT @@hostname, @@port, @@socket"

درج کریں کہ آپ نے کس اختتامی نقطے کی کوشش کی: مقامی Unix ساکٹ، آپ کا فارورڈنگ پورٹ یا نجی سامع۔ ان تین ناکامیوں کے علاج مختلف ہیں، اور کلائنٹ کے غلط localhost سے بات کرتے ہوئے VPN راستہ بدلنا بیکار محنت ہے۔ نوٹس میں SSH توثیق اور ڈیٹابیس توثیق بھی الگ رکھیں، کیونکہ ڈیسک ٹاپ کلائنٹ سے ایک میں ناکامی دوسرے میں ناکامی جیسی لگتی ہے۔ پھر کام ختم ہونے پر فارورڈ ہٹا دیں۔

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

متعلقہ مضامین