একাধিক OpenVPN সংযোগ: failover তালিকা, লিঙ্ক বন্ডিং নয়

একটি প্রোফাইলে দুটি remote লাইন দ্বিতীয় লেনের মতো দেখায়; আসলে সেগুলো দ্বিতীয় প্রচেষ্টা। প্রথম endpoint উত্তর দেওয়া বন্ধ করলে ক্লায়েন্ট পরেরটিতে যায় এবং সেশন আরও চওড়া হয় না। তালিকাটিকে শুরুতেই failover বলুন, নইলে ভুল নিয়ন্ত্রণে হাত দেবেন।

একটি remote তালিকা আপনাকে কী দেয়

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

প্রকৃত aggregation আলাদা এক যন্ত্র। একটি প্রবাহকে কয়েকটি পথে ভাগ করতে দুই প্রান্তেই সফটওয়্যার লাগে, যা ট্রাফিক ভাগ করে ক্রমে আবার জোড়া দেয়।

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

এক endpoint-এর সাথে সেটিংস রাখা ব্লক

সাধারণ remote লাইন একটি ঠিকানা বহন করে, মাঝে মাঝে একটি পোর্ট ও প্রোটোকলও। যখন endpoint-এর প্রক্সি দরকার, বা এমন ট্রান্সপোর্ট যা ফাইলের বাকি অংশ ব্যবহার করে না, তখন সেই সেটিংসগুলি একটি সংযোগ ব্লকে রাখুন যা সেগুলি তার সাথে রাখে। ইনলাইন ব্লক একটি .ovpn ফাইলেও কাজ করে, আর বেশিরভাগ প্রোফাইল এভাবেই আসে।

ব্লকের বাইরের সবকিছু সেই এন্ট্রিগুলির জন্য ডিফল্ট হিসেবে কাজ করে যেগুলি তা অগ্রাহ্য করে না। তাই একটি নির্মিত ব্লক আর চারটি সাধারণ remote এমনভাবে আচরণ করে যা ঠিকানার তালিকা ব্যাখ্যা করতে পারে না।

যে ব্লক আপনি চেনেন না তা মুছে ফেলা সৌন্দর্যরক্ষা নয়। যে endpoint-এর এটি ছিল, সেটি ফাইলের ডিফল্টে ফিরে যায়, যা তার শোনা ট্রান্সপোর্টের চেয়ে ভিন্ন হতে পারে। ভুল মোড়ক সরালে একটি এন্ট্রি ব্যর্থ হয় আর বাকিগুলি কাজ করে, ফলে এটি নষ্ট প্রোফাইল নয়, খারাপ সার্ভারের মতো দেখায়। সম্পাদনার আগে প্রতিটি remote তার ট্রান্সপোর্ট, পোর্ট ও প্রক্সিসহ পড়ুন।

পুনরায় চেষ্টার ক্রম ও remote-random-এর মূল্য

ক্রম গুরুত্বপূর্ণ, কারণ প্রতিটি মৃত এন্ট্রি পরের প্রচেষ্টার আগে সময় নষ্ট করে। যে endpoint চান সেটি প্রথমে রাখুন এবং বাকিগুলিকে ক্রমবদ্ধ বিকল্প হিসেবে দেখুন।

remote-random শুরুর ক্রম এলোমেলো করে, যা সমতুল্য সার্ভারগুলিতে লোড ছড়ায় এবং যখন একটি endpoint স্পষ্টভাবে প্রধান তখন উল্টো ফল দেয়। যেভাবেই হোক, ক্লায়েন্ট যে endpoint বেছেছে তা লগ করুন; সংযোগ ধীর লাগলে প্রোফাইলের নাম কিছুই বলে না। বিস্তারিত লগ থেকে লিঙ্ক লাইন grep করলে দেখা যায় সেশন কোথায় নামল।

অপারেটর মেশানো বিশ্বাসের বিবৃতি ভাঙে

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

আপনার যদি দুই প্রদানকারীর endpoint দরকার হয়, সেটি রাউটিং, প্রোফাইল সম্পাদনা নয়। টানেলের উপরে এর উত্তর দিন, যেখানে আপনি বলতে পারেন কোন ট্রাফিক কোন পথ নেবে।

অনুমান নয়, প্রতিটি এন্ট্রি পরীক্ষা করুন

অনুমোদিত প্রোফাইল হালনাগাদের পরে প্রতিটি প্রয়োজনীয় endpoint-এ ইচ্ছাকৃতভাবে সংযোগ করুন এবং কোন ট্রান্সপোর্ট উঠল তা নিশ্চিত করুন। বিস্তারিত রান এটি দৃশ্যমান করে। openvpn --config office.ovpn --verb 4 শুরু করুন এবং যে ঠিকানা প্রত্যাশা করেছিলেন তার জন্য লিঙ্ক লাইন পড়ুন। তারপর টানেলের পিছনের সম্পদ যাচাই করুন; একটি এন্ট্রি হ্যান্ডশেক শেষ করেও আপনাকে কোথাও না পৌঁছাতে পারে।

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

অপারেটর তালিকা বদলালেই তা আবার যাচাই করুন। আমদানি করা সেট কেবল তখনই কাজে লাগে যখন তার এন্ট্রিগুলি থাকে এবং আপনার ব্লক যে ট্রান্সপোর্টের কথা বলে তা বলতে পারে। OpenVPN 2.6 নির্দেশিকা এখানে remote, connection ও random-order নির্দেশাবলি কভার করে, আর সিনট্যাক্স নিয়ে সন্দেহ হলে এটিই যাচাই করার সংস্করণ।