একই হোস্টে সার্ভার চললে OpenVPN ক্লায়েন্ট থেমে যায়

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

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

উপসর্গটি উল্টো দিক থেকে পড়ুন

টানেলটি কখন মরে তা দিয়ে শুরু করুন। চালুর সময় বাইন্ড ত্রুটি শ্রবণ-পাশের দিকে ইঙ্গিত করে: কিছু ইতিমধ্যে সেই পোর্টের মালিক, আর OpenVPN তা ভাগ করার বদলে চালু হতে অস্বীকার করে। যে টানেল উঠে এসে তারপর চুপ হয়ে যায় তা রাউটিংয়ের দিকে ইঙ্গিত করে, কারণ অন্য ইনস্ট্যান্সের বসানো একটি রুট বাইরের সংযোগের প্যাকেটগুলোকে তাদের পথ থেকে সরিয়ে দিতে পারে।

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

প্রতি ইনস্ট্যান্সে একটি সকেট ও একটি ডিভাইস

শ্রবণরত সার্ভার তার পোর্ট বাইন্ড করে; আউটবাউন্ড ক্লায়েন্টেরও তার এনক্যাপসুলেটেড ট্রাফিকের জন্য একটি লোকাল পোর্ট দরকার। যখন দুজনেই একই হোস্টে থাকে, তখন ডিফল্ট ক্লায়েন্ট আচরণ সার্ভারের পোর্টের সঙ্গে সংঘর্ষ করতে পারে। ক্লায়েন্টের লোকাল পোর্ট পিন করা যায়, এবং যেখানে প্রতিপক্ষের নির্দিষ্ট সোর্স পোর্ট দরকার নেই সেখানে বাইন্ডিং বাদ দেওয়া যায়:

lport 1195
nobind
dev tun1

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

nobind ক্লায়েন্ট পক্ষের। সার্ভারকে এখনও বাইন্ড ও শ্রবণ করতে হবে, তাই লাইনটি সার্ভার কনফিগে কপি করবেন না, এবং যে ক্লায়েন্টের প্রতিপক্ষ নির্দিষ্ট সোর্স পোর্টে ফিল্টার করে তার বাইন্ডিং বন্ধ করবেন না।

ডিফল্ট রুটের জন্য একজন মালিক বাছুন

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

ip rule add from 10.9.0.2 table 120
ip route add default dev tun1 table 120
ip route get 10.9.0.2

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

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

স্ট্যাটাস লাইনে নয়, টেবিলে যাচাই করুন

সংযুক্ত বলে জানানো ক্লায়েন্ট কেবল তার কন্ট্রোল চ্যানেল প্রমাণ করে। প্রতিটি সংযোগের আগে ও পরে রাউটিং অবস্থা ক্যাপচার করুন, তারপর কার্নেলকে জিজ্ঞাসা করুন একটি বাস্তব গন্তব্য কোন ডিভাইস ব্যবহার করবে:

ip route show
ip route get 10.40.0.20
ss -lunp | grep 1194

দ্বিতীয় টানেল চালু হলে ভেন্ডর ঠিকানার জন্য নির্বাচিত ডিভাইস বদলে গেলে আপনার রুট সংঘর্ষ আছে। দুই প্রসেসই একই লোকাল পোর্টে দেখা গেলে আপনার সকেট সংঘর্ষ আছে। দ্বিতীয়টি ছাড়া প্রথমটি ঠিক করলে ব্যর্থতা কেবল পরের পুনঃসংযোগে সরে যায়।

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