MariaDB عبر VPN: أي 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 ليستعلم منها.
افصل إمكانية الوصول عن المصادقة
نص الخطأ يخبرك في أي طبقة أنت. اتصال مرفوض أو مهلة يعني أن العميل لم يصل قط إلى مستمع، فالحساب وكلمة مروره ليسا بعد موضع سؤال. ردّ رفض الوصول يعني أن الخادم أجاب، وهذا يثبت إمكانية الوصول ويشير إلى الحساب أو مطابقة المضيف أو بيانات الاعتماد.
المتطلبات الشبكية قائمتها الخاصة: مستمع مرتبط بالعنوان المقصود لا بالـ loopback فقط، وحركة مسموح بها إلى المنفذ المضبوط، ومسار عودة للرد. كل منها يمكن أن يفشل مستقلًا، والنفق العامل لا يستلزم أيًا منها. المستمع على loopback يقبل الاتصالات المحلية ويرفض كل اتصال بعيد، ما ينتج اتصالًا مرفوضًا يشبه حجب جدار حماية.
تحقق من عنوان الربط قبل فتح تذكرة مع فريق الشبكة. ss -lntp على مضيف قاعدة البيانات يُظهر أي عنوان ومنفذ يستمعان فعليًا، وهذا السطر الواحد يستبعد فئة كاملة من التخمينات.
أصلح بضيق ثم أعد الاختبار في الاتجاهين
أنشئ الحساب المقصود المؤهّل بالمضيف عبر العملية المعتمدة في المؤسسة، ببيانات اعتماد من المخزن المدعوم لا واحدة مشتركة أُلصقت في تذكرة. امنح فقط عمليات المخطط التي تحتاجها المهمة. تحويل تسجيل دخول بعيد فاشل إلى حساب root أو سياسة منح الكل أو مضيف بدل شامل يجعل الاختبار ينجح ويزيل الضابط الذي كنت تختبره. المنحة التي أضفتها على عجل هي التي لا يزيلها أحد لاحقًا.
أعد الاختبار بجلسة جديدة عبر المسار المقصود، ثم افحص الحالات السلبية. المسار الذي ينبغي حجبه يجب أن يظل محجوبًا، والعملية غير الممنوحة يجب أن تظل مرفوضة. هذان الفحصان هما ما يفصل حسابًا مُصلحًا عن حساب موسّع.
أخيرًا، سجّل عنوان المصدر المرصود واسم الحساب معًا. النفق يوفّر إمكانية الوصول؛ ولا تزال MariaDB تختار حسابها وتأذنه، ويحتاج الشخص التالي إلى الحقيقتين معًا لإعادة إنتاج نتيجتك.