একই হোস্টে OpenVPN সার্ভার ও ক্লায়েন্ট: ক্লায়েন্টরা কেন ঝরে পড়ে

যে মেশিনে আগেই একটি VPN সার্ভার চলে, সেখানে ক্লায়েন্ট প্রোফাইল যোগ করুন — প্রথম ক্ষতিটি হবে পুরোনো সার্ভিসটিই। নতুন টানেল হয়তো কখনোই তৈরি হয় না, আবার এমনও হতে পারে যে সেটি উঠে আসে কিন্তু সার্ভারের বিদ্যমান ক্লায়েন্টরা চুপচাপ উত্তর পাওয়া বন্ধ করে দেয়। দুটি সংঘর্ষ এই দুই পরিণতিই তৈরি করে: একটি টানেল পুল যা ইতিমধ্যে ব্যবহৃত হচ্ছে, এবং নতুন ক্লায়েন্ট-অর্ধেকের বসানো একটি ডিফল্ট রুট যা পুরো টেবিলটি ঢেকে দেয়। কোনওটিই OpenVPN ত্রুটির বার্তা দেয় না, তাই ব্যর্থতাটিকে সার্ভারের সমস্যা হিসেবে পড়া হয়।

একটি মেশিন, দুটি ভূমিকা, এবং উত্তরগুলো কোথায় যাবে — সে বিষয়ে দুটি বেমানান উত্তর।

একই পুল, দুটি সার্ভার: কে জেতে

প্রতিটি সার্ভার ইনস্ট্যান্সের নিজের একটি টানেল সাবনেট প্রয়োজন। server 10.8.0.0 255.255.255.0-এর মতো একটি লাইন দ্বিতীয় কনফিগারেশনে অনুলিপি করলে দুই ইনস্ট্যান্স একই প্রিফিক্স পায়, আর ফলাফল হয় শুরু করতে অস্বীকৃতি, নয়তো এমন নীরব প্রতিযোগিতা যেখানে এক সার্ভারের ক্লায়েন্টরা এমন ঠিকানা পায় যা অন্য সার্ভারও নিজের বলে মনে করে। আলাদা UDP পোর্ট আর আলাদা ডিভাইসের নাম কোনওই কাজে আসে না, কারণ কোনওটিই ঠিকানা-ক্ষেত্র স্পর্শ করে না। দ্বিতীয় পুলটি বদলান, এবং রুটগুলো যেখানেই এটির কথা বলে সেখানেই বদলান।

সম্পাদনার আগে কোনটি সক্রিয় তা তালিকা করুন: ip -4 addr show টানেল ডিভাইসগুলো তালিকাভুক্ত করে, ss -lunp শ্রোতাদের তালিকাভুক্ত করে, আর systemctl list-units ইউনিটগুলোর নাম দেয়। টানেল ঠিকানাগুলোর দিকে একবার চোখ বোলালেই বোঝা যায় পুলগুলো সংঘর্ষে লিপ্ত কি না।

ক্লায়েন্ট প্রোফাইল টেবিলে কী যোগ করে

ক্লায়েন্ট-অর্ধেক সংযুক্ত হওয়ার সঙ্গে সঙ্গেই রুট লেখে। redirect-gateway def1 ডিফল্ট রুটটিকে 0.0.0.0/1 প্লাস 128.0.0.0/1-এ ভাগ করে, দুটিই নতুন ডিভাইস দিয়ে রুট করা হয়, সঙ্গে দূরের সার্ভারের প্রতি একটি হোস্ট রুট যা ইচ্ছাকৃতভাবে ভৌত ইন্টারফেসে পিন করা থাকে। সেই পিনটি আছে যাতে টানেল নিজের পরিবহনের জন্য একটি পথ ধরে রাখতে পারে। বাকি সবকিছু, স্থানীয় সার্ভার তার নিজের ক্লায়েন্টদের যে উত্তর দিতে বাধ্য সেগুলিসহ, এখন নতুন ডিফল্ট অনুসরণ করে দূরের লিংক দিয়ে বেরিয়ে যায়।

তাহলে দ্বিতীয় সংঘর্ষটি ভাঙা টানেল নয়। এটি টেবিলের ভুল জায়গায় থাকা একটি কার্যকর টানেল।

ভূমিকা দুটি আলাদা রাখার তিনটি উপায়

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

যে পথই নেন, ব্যতিক্রমটিতে LAN নয়, স্থানীয় টানেল সাবনেটের নাম থাকতে হবে। স্থানীয় সার্ভার যে উত্তর পাঠায় তার গন্তব্য একটি টানেল ঠিকানা, তাই LAN-আকৃতির ব্যতিক্রম কখনও তার সঙ্গে মেলে না।

দুটি ইনস্ট্যান্সের মধ্যে দোষী কোনটি

ক্লায়েন্ট ইনস্ট্যান্সটি থামিয়ে পুরোনো ক্লায়েন্টগুলো আবার পরীক্ষা করুন। তাৎক্ষণিক পুনরুদ্ধার মানে রাউটিং, সার্ভার নয়। ক্লায়েন্টটি ফিরিয়ে আনুন এবং একটি মাত্র উত্তর ip route get দিয়ে অনুসরণ করুন, যাকে উৎস ও গন্তব্য — উভয় ঠিকানাই দেওয়া হয়েছে, যা কার্নেল যে পথ বেছে নেবে তা দেখায়, তারপর প্যাকেটগুলো আসলে যে ইন্টারফেস ব্যবহার করে তা tcpdump -ni any port 1194 দিয়ে দেখুন। সার্ভারের স্ট্যাটাস ফাইল, যা প্রতি কয়েক সেকেন্ডে status নির্দেশের মাধ্যমে লেখা হয়, সংযুক্ত ক্লায়েন্ট তালিকা এবং দুই দিকের বাইট কাউন্টার বহন করে।

সেই কাউন্টারগুলো একটির বিপরীতে অন্যটি পড়ুন। যে ট্রাফিক বেরিয়ে যায় আর কখনও ফেরে না, সেটি হ্যান্ডশেকের সমস্যা নয়, রাউটিংয়ের উত্তর।