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 বিতরণের প্রয়োজনীয়তা কভার করে, এবং উৎপাদন সংযোগ স্ট্রিং পরিবর্তনের আগে এটি যাচাই করার রেফারেন্স।