VPN ফেইলওভার: যখন ফেরত পথ পুরোনো টানেলে থেকে যায়

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

প্রথমে দুই প্রান্তের রুট লিখে রাখুন; এক সাইটের দৃশ্য অসামঞ্জস্যপূর্ণ পথ দেখাতে পারে না। সময়ের চাপে সবচেয়ে বেশি বাদ পড়া ধাপও এটি।

পরীক্ষার আগে দুই সাইটের রুট লিখুন

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

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

এটি দুই সাইটেই করুন। যে ব্যাকআপ এক দিকে পছন্দনীয় আর অন্য দিকে উপেক্ষিত, সেটি ঠিক সেই অসামঞ্জস্যই তৈরি করে যা আপনি এড়াতে চান।

প্রতিটি ধাপে অনুরোধ ও উত্তর লক্ষ্য করুন

একটি নিরীহ অনুমোদিত অ্যাপ্লিকেশন ব্যবহার করুন এবং তিনটি ধাপ লক্ষ্য করুন: স্বাভাবিক, প্রাথমিক ব্যর্থতা এবং পুনরুদ্ধার। প্রতিটি ধাপে লিখুন কোন টানেল অনুরোধ বহন করে আর কোনটি উত্তর বহন করে। পৌঁছানো যায় এমন পিয়ার ঠিকানা প্রমাণ করে না যে সুরক্ষিত অ্যাপ্লিকেশন পথটি কাজ করে। একমুখী প্রবাহ দৃশ্যমান হতে দুই সাইটেই তা ধরুন।

যদি অনুরোধ সরে যায় কিন্তু উত্তর না সরে, তাহলে ক্লায়েন্ট প্রিফিক্সে দূরবর্তী সাইটের রুট এবং ব্যাকআপের প্রতি তার পছন্দ পরীক্ষা করুন। এটি রাউটিং সিদ্ধান্ত, টানেল ব্যর্থতা নয়।

পরীক্ষার পরে মূল অবস্থা ফিরিয়ে আনুন এবং প্রাথমিক টানেল আবার পছন্দনীয় কি না তা নিশ্চিত করুন। পুনরুদ্ধার করা প্রাথমিক টানেল পছন্দনীয় না হলে তা অসমাপ্ত ফেইলওভার ডিজাইন।

গেটওয়ে বদলালে সেশন অবস্থা সামলান

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

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

শুধু নতুন অনুরোধ নয়, দীর্ঘ সেশন ধরে রাখা অ্যাপ্লিকেশনও পরীক্ষা করুন।

প্রাথমিক ফিরিয়ে আনুন এবং ফ্ল্যাপিং যাচাই করুন

রুট বিজ্ঞপ্তি বা পছন্দগুলো দোলাচল ছাড়াই স্থির হয় কি না নিশ্চিত করুন। ফ্ল্যাপিং প্রাথমিক টানেল স্পষ্ট বিভ্রাটের চেয়ে বেশি বিভ্রান্তিকর হতে পারে, কারণ প্রতিটি রূপান্তর অবস্থা রিসেট করে।

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