ভাসমান VPN ব্যাকআপ রুট দায়িত্ব নিচ্ছে না: ফেইলওভার চেকলিস্ট

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

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

ব্যাকআপকে যে ব্যর্থতা ঢাকতে হবে তার নাম দিন

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

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

দূরত্বকে কিছু শনাক্ত করতে বলা বন্ধ করুন

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

স্ট্যাটিক রুটের জন্য এর একটি স্পষ্ট ট্র্যাকার দরকার:

/ip route
add dst-address=10.20.0.0/24 gateway=192.0.2.1 distance=1 check-gateway=ping
add dst-address=10.20.0.0/24 gateway=wg-backup distance=10

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

প্রোবের নিজের প্যাকেট কোথায় যায় তা অনুসরণ করুন

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

প্রোবকে যে পথের বিচার করার কথা সেই পথে পিন করুন। RouterOS-এ স্বাভাবিক উপায় হলো প্রাথমিক গেটওয়ে দিয়ে মনিটরিং লক্ষ্যে একটি হোস্ট রুট, এমন ছোট স্কোপসহ যে অন্য কোনো রুট তা রিজলভ করতে পারে না; RouterOS ম্যানুয়ালের পুনরাবৃত্ত ফেইলওভার উদাহরণ ঠিক এটি তৈরি করে। ব্যাকআপ সক্রিয় অবস্থায় লাইভ টেবিলে এটি নিশ্চিত করুন, কনফিগ মন্তব্য থেকে নয়:

/ip route print detail where dst-address=203.0.113.10
# gateway should still be the primary next hop

লক্ষ্য যোগ করার আগে প্রোবের ফলাফলের অর্থ নির্ধারণ করুন

একটি লক্ষ্য যা ICMP প্রত্যাখ্যান করে বা রক্ষণাবেক্ষণে যায় দেখতে ঠিক পথের ব্যর্থতার মতো, আর নিয়ম ছাড়া তিনটি লক্ষ্য আপনাকে শুধু তিনটি মত দেয়। আগে নিয়ম ঠিক করুন, তারপর বাস্তবায়ন করুন: যেমন, তিনটির মধ্যে দুটি লক্ষ্য দুটি ধারাবাহিক বিরতিতে ব্যর্থ হলে প্রাথমিক ডাউন গণ্য হয়, যা রানবুকে লিখুন যেখানে পরের ব্যক্তি তা পাবে।

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

ফেরত পথ ও সেশন গল্প পরীক্ষা করুন

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

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

গ্রহণযোগ্যতার ক্রমটি চালান

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

নীরব কেসটিই ডিজাইন আলাদা করে। যদি ব্যাকআপ সেখানে দায়িত্ব না নেয়, তবে আপনি পথ-মনিটর নয়, লিংক-মনিটর বানিয়েছেন। এটি গ্রহণযোগ্য কিনা ঠিক করুন, এবং সীমাবদ্ধতাটি যেখানে অন-কল ইঞ্জিনিয়ার পড়বেন সেখানে লিখুন। দ্বিতীয় সংযুক্ত টানেল নিজে নিজে সম্পূর্ণ ব্যাকআপ নীতি নয়.