VPN کے ذریعے MySQL: سرور کی تصدیق کریں، صرف خفیہ کاری نہیں
غلط ہوسٹ کی طرف خفیہ کاری بھی غلط ہے۔ ssl-mode اقدار کا موازنہ کریں، پھر ایسا کنکشن چلائیں جو آپ کے مطلوبہ سرور کا نام لے اور اسے ثابت کرے۔
آپ 10.20.4.15 پر کنکشن محفوظ کرتے ہیں، VPN گر جاتا ہے، اور کلائنٹ پھر بھی جڑتا ہے۔ یہ اچھی خبر نہیں ہے۔ نجی پتہ آپ کے کسی بھی روٹنگ سیاق و سباق کے اندر ایک مقام ہے، اور بہت سے نیٹ ورک وہی حدود استعمال کرتے ہیں۔ کلائنٹ ایک MySQL سرور تک پہنچ گیا، بس شاید آپ کے سرور تک نہیں۔
حل کے دو حصے ہیں، اور ان میں سے صرف ایک نیٹ ورک کے بارے میں ہے۔ کنکشن کو اس کے مطلوبہ راستے پر رکھیں، اور کلائنٹ سے اس سرور کی تصدیق کروائیں جس سے وہ بات کر رہا ہے۔ پہلا حصہ وہ جگہ ہے جہاں VPN مدد کرتا ہے؛ دوسرا حصہ کنفیگر کرنا ہوگا۔
ٹھیک ٹھیک کس طرف خفیہ کیا گیا ہے؟
TLS بات چیت کو درمیان میں موجود کسی بھی شخص سے بچاتا ہے اور اس بارے میں کچھ نہیں کہتا کہ اینڈ پوائنٹ خود کو کون کہتا ہے، جب تک کلائنٹ جانچ نہ کرے۔ کسی قابل اعتماد اتھارٹی کے خلاف توثیق شدہ سرٹیفکیٹ ثابت کرتا ہے کہ سرٹیفکیٹ اسی اتھارٹی سے آیا ہے۔ یہ ثابت نہیں کرتا کہ سرٹیفکیٹ اس ہوسٹ نام کے لیے جاری ہوا تھا جس تک آپ پہنچنا چاہتے تھے، اور یہ الگ سوالات ہیں۔
یہ نظریاتی خلا نہیں ہے۔ کیپٹیو پورٹل، غلط VRF کی غلطیاں اور ایک دوسرے پر چڑھنے والے پتہ منصوبے سب ایسا سرور بناتے ہیں جو آپ کے ساتھ TLS پر بات چیت کے لیے مکمل طور پر تیار ہے۔ اگر کلائنٹ صرف خفیہ کاری کا مطالبہ کرے، تو سیشن نجی ہے لیکن غلط ڈیٹا بیس کی طرف اشارہ کرتا ہے۔
اس لیے متعلقہ سوال یہ نہیں کہ کنکشن خفیہ ہے یا نہیں، بلکہ یہ ہے کہ آیا یہ اسی شناخت کی طرف خفیہ ہے جس کا آپ نے ارادہ کیا تھا۔ MySQL کے کلائنٹ میں، یہ فرق مکمل طور پر ssl-mode ترتیب میں رہتا ہے۔
عملی طور پر پانچ ssl-mode اقدار
پانچ اقدار موجود ہیں، اور ان میں سے صرف ایک اس گائیڈ کے سوال کا جواب دیتی ہے۔ جدول یہ بتاتا ہے کہ ہر ایک واقعی کیا ضمانت دیتا ہے، نہ کہ اس کا نام کیا تجویز کرتا ہے۔
| Mode | What it guarantees |
|---|---|
DISABLED | No TLS at all; everything on the wire is readable |
PREFERRED | Tries TLS and falls back to plaintext when the account and server allow it, so it is not a fail-closed requirement |
REQUIRED | Refuses to connect without TLS, and does not validate the certificate |
VERIFY_CA | Validates the server certificate against the configured CA and does not check the hostname |
VERIFY_IDENTITY | Validates 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 کی ناکامی کا مطلب ہے کہ زنجیر تصدیق نہیں ہوتی اور آپ کو دیکھنا چاہیے کہ سرور سرٹیفکیٹ پر کس CA نے دستخط کیے۔ ہوسٹ نام کی ناکامی کا مطلب ہے کہ زنجیر درست ہے اور نام مطابقت نہیں رکھتا، جس کا عام مطلب یہ ہے کہ آپ غلط سرور سے نہیں، بلکہ درست سرور سے غلط نام پر جڑے ہیں۔
پرامپٹ کا ظاہر ہونا اس بات کا ثبوت نہیں کہ پاس ورڈ پہلے ہی بھیج دیا گیا ہے، اور ناکام کنکشن یہ ثابت نہیں کرتا کہ کلائنٹ سے کچھ بھی باہر نہیں گیا۔ اگر آپ ماضی کے واقعے کی تشکیل نو کر رہے ہیں تو کلائنٹ، اس کی ترتیب، تصدیق کا پلگ ان اور ناکام مرحلہ شناخت کریں۔ آخری غلطی پیغام سے نمائش کا اندازہ لگانا اندازہ ہے۔
جب نام سرنگ سے آئے
مقامی پورٹ فارورڈنگ شناخت کی جانچ کو اس طرح توڑتی ہے جو لوگوں کو حیران کرتی ہے۔ اگر آپ مقامی پورٹ کو ڈیٹا بیس پر فارورڈ کریں اور localhost سے جڑیں، تو کلائنٹ سرٹیفکیٹ کی localhost کے خلاف توثیق کرتا ہے، اور اس نام کے لیے کوئی سرٹیفکیٹ جاری نہیں ہوا تھا۔ کنکشن مکمل طور پر محفوظ ہو سکتا ہے اور تصدیق پھر بھی ناکام ہوگی، جو یہ ہے کہ جانچ مقصد کے مطابق کام کر رہی ہے۔
دو ایماندار جواب ہیں۔ فارورڈ شدہ اینڈ پوائنٹ کو ایسا نام دیں جو لوپ بیک پتے پر حل ہو اور سرور سرٹیفکیٹ میں ظاہر ہو، یا ہوسٹ نام کو شروع سے آخر تک استعمال کریں تاکہ کلائنٹ حقیقی شناخت کی تصدیق کرے۔ پہلا ڈویلپرز کے لیے آسان ہے اور سرٹیفکیٹ کا کام مانگتا ہے؛ دوسرا سوچنے میں آسان ہے اور اکثر آٹومیشن کے لیے درست ڈیفالٹ ہے۔ فارورڈنگ کے کام کرنے کے لیے تصدیق بند کرنا اس خصوصیت کو پھینک دیتا ہے جو آپ شامل کرنے کی کوشش کر رہے تھے۔
قبولیت تین شرطیں ہیں
قبولیت کے امتحان کو تین الگ بیانات کے طور پر لکھیں: کنکشن نے مطلوبہ راستہ استعمال کیا، خفیہ کاری ترجیح نہیں بلکہ لازمی تھی، اور سرور کی شناخت قابل اعتماد مواد کے خلاف تصدیق ہوئی۔ سبز VPN آئیکن ان میں سے کسی کو قائم نہیں کرتا۔
GUI کلائنٹس اور MariaDB کے لیے، جھنڈے کے ہجے کے ویسے ہی لاگو ہونے کا اندازہ لگانے کے بجائے فروش کی اپنی دستاویزات دیکھیں۔ MySQL کی خفیہ شدہ کنکشن دستاویزات طریقوں کے درمیان فرق اور CA کی تقسیم کی ضرورت کا احاطہ کرتی ہیں، اور پروڈکشن کنکشن سٹرنگ تبدیل کرنے سے پہلے یہی وہ حوالہ ہے جو جانچنا چاہیے۔