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 এখনো নিজের অ্যাকাউন্ট বেছে নেয় ও অনুমোদন দেয়, এবং পরবর্তী ব্যক্তির আপনার ফলাফল পুনরুৎপাদন করতে দুটি তথ্যই দরকার।