VPN-এর মাধ্যমে MySQL localhost: এটি এখনও স্থানীয় প্রক্রিয়াই বোঝায়

অফিস সার্ভারের অ্যাপটি localhost ঠিকানায় MySQL-এ সংযোগ করে, আপনি সেই হোস্টনামটি ডেস্কটপ ক্লায়েন্টে কপি করেন, আর সংযোগটি হয় ব্যর্থ হয় বা অন্য একটি ডেটাবেস খুলে ফেলে। VPN শব্দটির অর্থে কিছুই বদলায়নি: localhost এখনও সেই মেশিনকেই বোঝায় যেটি ক্লায়েন্ট চালায়। VPN প্যাকেট সরিয়েছে, ইন্টারফেস নয়। কোনো রুটে হাত দেওয়ার আগে ঠিক করুন ল্যাপটপটি কোন প্রান্তে পৌঁছাবে।

ধাপ 1: ল্যাপটপটি কোন প্রান্তে পৌঁছাবে তা ঠিক করুন

দুটি নকশাই বৈধ এবং তারা ভিন্ন প্রশ্নের উত্তর দেয়। সরাসরি অ্যাক্সেস মানে ডেটাবেস এমন একটি ব্যক্তিগত ঠিকানায় শোনে যেখানে টানেল পৌঁছায়, আর ল্যাপটপ সেই ঠিকানায় সংযোগ করে। ফরওয়ার্ড করা অ্যাক্সেস মানে ডেটাবেস loopback-এ থাকে এবং একটি SSH সেশন পোর্টটি আপনার মেশিনে বহন করে। একটি বেছে নিন সচেতনভাবে, কারণ দুটো মেশালে এমন সংযোগ তৈরি হয় যা ভুল কারণে কাজ করে।

সরাসরি অ্যাক্সেসের জন্য, ডেটাবেস হোস্টের নিজস্ব ব্যক্তিগত নাম বা ঠিকানা এবং তার পোর্ট যিনি এটি চালান তার কাছ থেকে নিন। VPN গেটওয়ের ঠিকানা ডেটাবেসের ঠিকানা নয়, যদি না সেটি একই মেশিন হয়। তারপর নিশ্চিত করুন লিসেনারটি সত্যিই সেই ইন্টারফেসে বাঁধা, কারণ কোনো ইন্টারফেসের দিকে রুট সেই ইন্টারফেসে লিসেনার তৈরি করে না।

ধাপ 2: পোর্টটি কেবল তখনই ফরওয়ার্ড করুন যখন লিসেনার স্থানীয় থাকে

যদি ডেটাবেসকে কেবল loopback-এ থাকতে হয়, তবে SSH দিয়ে এটি ফরওয়ার্ড করুন এবং স্থানীয় প্রান্তটিও loopback-এ বাঁধুন। বাঁদিকের বাইন্ড ঠিকানাটি আপনার ল্যাপটপের; ডানদিকের লক্ষ্যটি SSH সার্ভারের দিক থেকে ব্যাখ্যা করা হয়, যেমনটি OpenSSH রেফারেন্স বর্ণনা করে। এই দুটি ভূমিকা উল্টে যাওয়াই সাধারণ কারণ যেখানে ফরওয়ার্ড কাজ করছে বলে মনে হয় কিন্তু কিছুতে সংযোগ করে না।

ssh -N -o ExitOnForwardFailure=yes -L 127.0.0.1:13306:127.0.0.1:3306 [email protected]
ss -ltn 'sport = :13306'

যদি SSH ডেটাবেস হোস্টের বদলে কোনো জাম্প হোস্টে পৌঁছায়, তবে ডানদিকের loopback জাম্প হোস্টকেই বোঝায়, আর লক্ষ্যটি এমন ঠিকানায় বদলাতে হবে যেখানে সেই হোস্ট পৌঁছায়। ExitOnForwardFailure ফরওয়ার্ড স্থাপনে ব্যর্থতা ধরে, কিন্তু তা প্রমাণ করে না যে লক্ষ্যে পরের সংযোগগুলো সফল। হোস্ট-কি যাচাই চালু রাখুন, এবং ফরওয়ার্ডিং পোর্টটি সব ইন্টারফেসে বেঁধে আপনার পুরো LAN-কে দেবেন না।

থামুন যদি ডেটাবেসকে কেবল loopback-এ থাকতে হয় এবং আপনি SSH ব্যবহার করতে না পারেন। তখন সরাসরি অ্যাক্সেস ভুল নকশা, জোর করে চাপানো কোনো কনফিগারেশন নয়।

ধাপ 3: ক্লায়েন্টকে TCP-তে বাধ্য করুন

Unix-এ localhost দেওয়া একটি MySQL ক্লায়েন্ট ডিফল্টভাবে একটি Unix সকেট বেছে নেয়, তাই কেবল পোর্ট বদলালে সেটি এমন সকেট খুঁজতে থাকে যার সঙ্গে আপনার ফরওয়ার্ডের কোনো সম্পর্ক নেই। স্পষ্ট TCP প্রোটোকল ও loopback ঠিকানা ব্যবহার করে ক্লায়েন্টকে আপনার ফরওয়ার্ডিং পোর্টে সংযোগ খুলতে বাধ্য করুন।

mysql --protocol=TCP --host=127.0.0.1 --port=13306 --user=DB_USER --password

মান ছাড়া পাসওয়ার্ড অপশনটি গোপন কথাটি কমান্ড লাইনে না রেখে জিজ্ঞাসা করে, আর এই অভ্যাসটাই ধরে রাখার মতো। অন্য টুলগুলোর একই পার্থক্যের জন্য নিজস্ব সুইচ আছে, এবং কিছু ড্রাইভারও localhost-কে বিশেষভাবে দেখে। ফ্ল্যাগটি এসেছে ধরে না নিয়ে আপনার ক্লায়েন্ট কী করে তা যাচাই করুন। ডেটাবেস অ্যাকাউন্টেরও এমন অনুমতি দরকার যা সার্ভার যে উৎস দেখে তার সঙ্গে মেলে, আর সেটি আপনার ল্যাপটপ নয়, ফরওয়ার্ডিং হোস্ট।

থামুন যদি টুলটিকে TCP-তে বাধ্য করা না যায়। তখন অন্য ক্লায়েন্ট ব্যবহার করুন, বা ব্যক্তিগত লিসেনারে সরাসরি অ্যাক্সেস ব্যবহার করুন।

ধাপ 4: আপনি আসলে কোন প্রান্তে পৌঁছেছেন তা প্রমাণ করুন

সার্ভারকে জিজ্ঞাসা করুন সে সংযোগটিকে কী মনে করে। হোস্টনাম, পোর্ট ও সকেট ভেরিয়েবল বলে দেয় আপনি TCP-তে এসেছেন কি না এবং কোন লিসেনার উত্তর দিয়েছে, আর সংযোগের তালিকা দেখায় সার্ভার যে উৎস ঠিকানা লিখেছে। এই প্রমাণ আরেকটি রুট বদলের চেয়ে বেশি কাজে লাগে।

mysql --protocol=TCP -h 127.0.0.1 -P 13306 -u DB_USER -p -e "SELECT @@hostname, @@port, @@socket"

আপনি কোন প্রান্ত চেষ্টা করেছেন তা লিখে রাখুন: স্থানীয় Unix সকেট, আপনার ফরওয়ার্ডিং পোর্ট বা ব্যক্তিগত লিসেনার। এই তিন ব্যর্থতার সমাধান আলাদা, আর ক্লায়েন্ট যখন ভুল localhost-এর সঙ্গে কথা বলছে তখন VPN রুট বদলানো বৃথা পরিশ্রম। নোটে SSH প্রমাণীকরণ ও ডেটাবেস প্রমাণীকরণও আলাদা রাখুন, কারণ ডেস্কটপ ক্লায়েন্ট থেকে একটির ব্যর্থতা অন্যটির ব্যর্থতার মতো দেখায়। তারপর কাজ শেষ হলে ফরওয়ার্ডটি সরিয়ে দিন।

চেকলিস্ট শেষ হয় যখন আপনি প্রান্তটি, ক্লায়েন্ট প্রোটোকল, সার্ভার যে উৎস ঠিকানা দেখেছে এবং যে অনুমতি তা দিয়েছে—এগুলোর নাম বলতে পারেন। চারটি তথ্য, আর পরের সংযোগ সমস্যাটি এক বিকেলের বদলে কয়েক মিনিটে শেষ হয়।