تحفظ اتصالًا إلى 10.20.4.15، فينقطع الـ VPN، ومع ذلك يظل العميل يتصل. هذه ليست أخبارًا سارة. العنوان الخاص موضع داخل أي سياق توجيه تكون فيه، وكثير من الشبكات تستخدم النطاقات نفسها. لقد وصل العميل إلى خادم MySQL، لكنه ربما لم يصل إلى خادمك.

للإصلاح شقّان، وواحد فقط منهما يتعلق بالشبكة. أبقِ الاتصال على مساره المقصود، واجعل العميل يتحقق من هوية الخادم الذي يتحدث إليه. الشق الأول هو حيث يساعد الـ VPN؛ أما الشق الثاني فيجب إعداده.

مشفَّر إلى ماذا، بالتحديد؟

يحمي TLS المحادثة من أي شخص في الوسط، ولا يقول شيئًا عن هوية الطرف الآخر ما لم يتحقق العميل منها. الشهادة التي تتحقق مقابل جهة موثوقة تثبت أن الشهادة صادرة عن تلك الجهة. لكنها لا تثبت أن الشهادة صدرت لاسم المضيف الذي قصدت الوصول إليه، وهذان سؤالان مختلفان.

هذه ليست ثغرة نظرية. بوابات الالتقاط وأخطاء الـ VRF الخطأ ومخططات العناوين المتداخلة كلها تنتج خادمًا مستعدًا تمامًا للتفاوض معك على TLS. وإذا كان العميل يشترط التشفير فقط، فالجلسة خاصة لكنها متجهة إلى قاعدة البيانات الخطأ.

إذن السؤال ذو الصلة ليس هل الاتصال مشفَّر، بل هل شُفِّر إلى الهوية التي قصدتها. في عميل MySQL، يعيش هذا التمييز بالكامل في إعداد ssl-mode.

قيم ssl-mode الخمس عمليًا

توجد خمس قيم، وواحدة فقط منها تجيب عن سؤال هذا الدليل. يسرد الجدول ما يضمنه كل منها فعليًا لا ما يوحي به اسمه.

ModeWhat it guarantees
DISABLEDNo TLS at all; everything on the wire is readable
PREFERREDTries TLS and falls back to plaintext when the account and server allow it, so it is not a fail-closed requirement
REQUIREDRefuses to connect without TLS, and does not validate the certificate
VERIFY_CAValidates the server certificate against the configured CA and does not check the hostname
VERIFY_IDENTITYValidates the CA and checks that the certificate names the host the client used

الصف الأخير وحده يجيب عن سؤال هذا المقال. PREFERRED يستحق التنبيه إليه من تلقاء نفسه، لأن عميلًا ينتقل بصمت إلى نص صريح أسوأ من عميل يرفض: تظن أن لديك تشفيرًا بينما تقول لقطة الحزم عكس ذلك.

اتصال يمكنك تنفيذه اليوم

الأمر أدناه هو الشكل الذي تستخدمه، مع عنصرين نائبين: اسم قاعدة البيانات المعتمد وملف CA حُصل عليه عبر قناة معتمدة. لا ينبغي أخذ أي منهما من أي شيء يعرضه عليك الخادم عند أول اتصال.

mysql --host=db.corp.example --user=app_reader \
  --ssl-mode=VERIFY_IDENTITY \
  --ssl-ca=/approved/path/ca.pem --password

--password بلا قيمة يطلب الإدخال، ما يبقي السر خارج قائمة العمليات وخارج سجل الصدفة. هذه عادة صغيرة بعائد كبير على مضيفات القفز المشتركة، حيث يكون سطر الأوامر مرئيًا لمستخدمين آخرين.

عندما يفشل هذا، يميّز نص الخطأ الحالات أفضل من الحدس. فشل CA يعني أن السلسلة لا تتحقق، وعليك البحث عن الجهة التي وقعت شهادة الخادم. فشل اسم المضيف يعني أن السلسلة سليمة والاسم غير مطابق، وهذا يعني عادة أنك اتصلت بالخادم الصحيح باسم خاطئ لا بخادم خاطئ.

ظهور مطالبة ليس دليلًا على أن كلمة مرور أُرسلت بالفعل، وفشل الاتصال لا يثبت أن شيئًا لم يغادر العميل. إذا كنت تعيد بناء حادث سابق، فحدّد العميل وإعداده وإضافة المصادقة والمرحلة التي فشلت. تقدير الانكشاف من رسالة الخطأ الأخيرة تخمين.

حين يأتي الاسم من نفق

تكسر إعادة توجيه المنفذ المحلي فحص الهوية بطريقة تفاجئ الناس. إذا أعدت توجيه منفذ محلي إلى قاعدة البيانات واتصلت بـ localhost، فإن العميل يتحقق من الشهادة مقابل localhost، ولم تصدر شهادة بهذا الاسم. قد يكون الاتصال آمنًا تمامًا ومع ذلك سيفشل التحقق، وهذا هو الفحص يعمل كما هو مقصود.

هناك إجابتان صادقتان. أعطِ الطرف المُعاد توجيهه اسمًا يُحلّ إلى عنوان الاسترجاع ويظهر في شهادة الخادم، أو استخدم اسم المضيف من البداية إلى النهاية ليتحقق العميل من الهوية الحقيقية. الأول مريح للمطورين ويتطلب عملًا على الشهادات؛ والثاني أبسط في التفكير وغالبًا هو الافتراضي الصحيح للأتمتة. تعطيل التحقق ليعمل التوجيه يلقي بالميزة التي كنت تحاول إضافتها.

القبول ثلاثة شروط

اكتب اختبار القبول في ثلاث عبارات منفصلة: استخدم الاتصال المسار المقصود، وكان التشفير مطلوبًا لا مفضلًا، وتم التحقق من هوية الخادم مقابل مواد موثوقة. أيقونة VPN خضراء لا تثبت أيًّا منها.

بالنسبة لعملاء واجهة المستخدم الرسومية ولـ MariaDB، راجع وثائق البائع نفسه بدلًا من افتراض أن كتابة العلامة تنتقل كما هي. وثائق MySQL للاتصالات المشفَّرة تغطي فروق الأوضاع ومتطلب توزيع CA، وهي المرجع الذي تراجعه قبل تغيير سلسلة اتصال إنتاجية.

مقالات ذات صلة