VPN پر MariaDB: سرور کون سا user@host دیکھتا ہے؟
اکاؤنٹ صارف اور میزبان دونوں سے مل کر منتخب ہوتا ہے۔ وہ ماخذ تلاش کریں جو سرور نے دیکھا، CURRENT_USER() پڑھیں، پھر اسی قطار کو درست کریں، اجازت کو نہیں۔
ایک ہی صارف نام دو مختلف راستوں سے لکھیں اور MariaDB آپ کو دو مختلف اکاؤنٹس کے طور پر تصدیق کر سکتا ہے۔ اکاؤنٹس صارف اور میزبان دونوں پر مبنی ہوتے ہیں، اس لیے 'reporter'@'localhost' اور 'reporter'@'10.90.0.23' الگ پاس ورڈز اور الگ اجازتوں والی الگ قطاریں ہیں۔ VPN پر دلچسپ سوال یہ نہیں کہ صارف نے کون سا نام لکھا، بلکہ یہ ہے کہ سرور نے کون سا ماخذ پتہ دیکھا۔
وہ ماخذ مقرر کریں جو سرور واقعی دیکھتا ہے
لیپ ٹاپ سے نہیں، ڈیٹا بیس میزبان سے پیچھے کی طرف کام کریں۔ کلائنٹ جو پتہ سمجھتا ہے کہ اس کے پاس ہے وہ کئی امکانات میں سے صرف ایک ہے:
| Path | Source MariaDB sees |
|---|---|
| Routed tunnel, no translation | The client's inner VPN address |
| Gateway source translation | The gateway's translated address |
| SSH local forward | The SSH server's address |
| Public exit, no tunnel | Whatever the ISP handed out |
اسے طے کرنے کے لیے سرور کی طرف کے شواہد استعمال کریں۔ کنکشن لاگ، فعال سیشنوں کی فہرست یا عام لاگ میں عارضی اندراج وہ پتہ دکھاتا ہے جو سرور نے قبول کیا۔ براؤزر سے لیپ ٹاپ کا عوامی IP ایک اور حقیقت ہے اور اکثر گمراہ کن ہوتا ہے۔
MariaDB کے منتخب کردہ اکاؤنٹ سے ملائیں
اکاؤنٹ کا انتخاب اجازتوں کے اتحاد کی بجائے دستاویزی ترتیب کی پیروی کرتا ہے۔ میزبان کی درست مطابقت وائلڈ کارڈ پر فوقیت رکھتی ہے، اور گمنام صارف کی قطاریں اس طرح مطابقت میں شریک ہوتی ہیں جو ان لوگوں کو حیران کرتی ہیں جو سمجھتے ہیں کہ صرف نام فیصلہ کرتا ہے۔ سرور ایک قطار منتخب کرتا ہے؛ یہ ہر ایک ہی نام والی قطار کے مراعات یکجا نہیں کرتا۔ حوالہ ایک بار پڑھنا دوپہر بھر اندازے آزمانے سے زیادہ قیمتی ہے۔
اس کا مطلب ہے کہ 'reporter'@'%' میں اجازت شامل کرنا کچھ نہیں بدل سکتا اگر سیشن 'reporter'@'10.90.0.23' کے طور پر تصدیق شدہ ہو۔ درستی اسی قطار پر ہونی چاہیے جو منتخب ہوئی تھی، اسی لیے اکاؤنٹ کی شناخت اجازتیں تبدیل کرنے سے پہلے آتی ہے۔
وہ اکاؤنٹ پڑھیں جو سیشن واقعی استعمال کرتا ہے
SELECT USER(), CURRENT_USER();
SHOW GRANTS;CURRENT_USER() اس اکاؤنٹ کا نام بتاتا ہے جس نے سیشن کی تصدیق کی؛ USER() بتاتا ہے کہ کلائنٹ نے کیا مانگا اور مختلف ہو سکتا ہے۔ انہیں عام اعلیٰ سطحی استفسار کے طور پر چلائیں، تعریف کنندہ سیاق و سباق والے محفوظ روٹین کے اندر سے نہیں، ورنہ جواب آپ کے سیشن کی بجائے روٹین کے مالک کی وضاحت کریں گے۔
ناکام لاگ ان ان میں سے کچھ نہیں چلا سکتا، اور یہی وہ صورت ہے جہاں منتظم کو اکاؤنٹ کی تعریفیں اور سرور کے کنکشن کے شواہد جانچنے پڑتے ہیں۔ اس کی منصوبہ بندی کریں: مسترد شدہ لاگ ان کو ڈیبگ کرنے والے کے پاس عام طور پر پوچھنے کے لیے کوئی SQL سیشن نہیں ہوتا۔
رسائی کو تصدیق سے الگ کریں
خرابی کا متن بتاتا ہے کہ آپ کس پرت میں ہیں۔ مسترد شدہ کنکشن یا وقت کا خاتمہ یعنی کلائنٹ کبھی سننے والے تک نہیں پہنچا، اس لیے اکاؤنٹ اور اس کا پاس ورڈ ابھی سوال میں نہیں ہیں۔ رسائی مسترد ہونے کا جواب یعنی سرور نے جواب دیا، جو رسائی ثابت کرتا ہے اور اکاؤنٹ، میزبان کی مطابقت یا اسناد کی طرف اشارہ کرتا ہے۔
نیٹ ورک کی پیشگی شرطیں اپنی الگ فہرست ہیں: صرف لوپ بیک پر نہیں بلکہ مطلوبہ پتے پر بندھا سننے والا، ترتیب شدہ پورٹ پر اجازت یافتہ ٹریفک اور جواب کے لیے واپسی کا راستہ۔ ہر ایک آزادانہ ناکام ہو سکتا ہے، اور کام کرنے والی سرنگ ان میں سے کسی کو نہیں ظاہر کرتی۔ لوپ بیک پر سننے والا مقامی کنکشن قبول کرتا ہے اور ہر دور دراز کو مسترد کرتا ہے، جو فائر وال بلاک جیسا دکھنے والا مسترد شدہ کنکشن پیدا کرتا ہے۔
نیٹ ورک ٹیم کے ساتھ ٹکٹ کھولنے سے پہلے بائنڈ پتہ جانچیں۔ ڈیٹا بیس میزبان پر ss -lntp دکھاتا ہے کہ کون سا پتہ اور پورٹ واقعی سن رہے ہیں، اور وہ ایک سطر اندازوں کی پوری قسم کو خارج کر دیتی ہے۔
تنگ دائرے میں مرمت کریں، پھر دونوں سمتوں میں دوبارہ جانچیں
تنظیم کے منظور شدہ عمل کے ذریعے مطلوبہ میزبان کے لیے اہل اکاؤنٹ بنائیں، ٹکٹ میں چسپاں مشترکہ اسناد کی بجائے معاون ذخیرے سے اسناد کے ساتھ۔ صرف وہی اسکیما کارروائیاں دیں جن کی کام کو ضرورت ہے۔ ناکام دور دراز لاگ ان کو روٹ اکاؤنٹ، سب کچھ دینے کی پالیسی یا وسیع وائلڈ کارڈ میزبان بنانا جانچ پاس کرا دیتا ہے اور وہ کنٹرول ہٹا دیتا ہے جو آپ جانچ رہے تھے۔ جلد بازی میں شامل کی گئی اجازت وہی ہے جسے بعد میں کوئی نہیں ہٹاتا۔
مطلوبہ راستے سے نئے سیشن کے ساتھ دوبارہ جانچیں، پھر منفی صورتیں دیکھیں۔ جس راستے کو مسدود ہونا چاہیے وہ اب بھی مسدود رہے، اور جو کارروائی نہیں دی گئی وہ اب بھی مسترد رہے۔ یہی دو جانچیں درست شدہ اکاؤنٹ کو پھیلائے گئے اکاؤنٹ سے الگ کرتی ہیں۔
آخر میں، مشاہدہ شدہ ماخذ پتہ اور اکاؤنٹ کا نام اکٹھے درج کریں۔ سرنگ رسائی فراہم کرتی ہے؛ MariaDB اب بھی اپنا اکاؤنٹ منتخب اور مجاز کرتا ہے، اور اگلے شخص کو آپ کا نتیجہ دہرانے کے لیے دونوں حقائق درکار ہیں۔