DPD টাইমার ছোট করলে VPN ফেইলওভার দ্রুত হবে না

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

চারটি ধাপ, যার একটির সময় আপনি মাপতে পারেন

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

IKEv2-এর লাইভনেস নিয়মাবলি পিয়ার ও তার বিনিময় সম্পর্কে প্রমাণ বর্ণনা করে, আর সেই পিয়ারের পেছনের কোনো ডেটাবেস বা ফাইল পরিষেবা সম্পর্কে কিছুই বলে না। লাইভনেস টাইমআউটকে পুরো পথের স্বাস্থ্য পরীক্ষা হিসেবে পড়া হলো সেই ভুল যা টাইমার-শিকার শুরু করে।

কেন টাইমার সবচেয়ে কম আকর্ষণীয় সংখ্যা

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

অন্য ধাপগুলো মোটেই টাইমার নয়। পুনঃসংযোগের ব্যাকঅফ, ইন্টারঅ্যাকটিভ প্রমাণীকরণ প্রম্পট বা এমন ক্লায়েন্ট যা কেবল রিস্টার্টে তার কনফিগারেশন পুনর্মূল্যায়ন করে—এগুলোর প্রত্যেকটি বিভ্রাটে প্রাধান্য পেতে পারে, যখন প্রতিটি প্রোটোকল টাইমার আরামসে নিচুতে থাকে।

যে ধাপটি সত্যিই ধীর তা মাপুন

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

ip -4 route get 203.0.113.10
tcpdump -ni any -c 20 "esp or icmp"

বিকল্প এন্ডপয়েন্ট যদি কখনোই উত্তর না দেয়, কোনো টাইমার পরিবর্তনই সাহায্য করে না, কারণ পৌঁছানো না যাওয়া সনাক্তকরণের সমস্যা নয়। নতুন নিরাপত্তা অবস্থা দ্রুত তৈরি হলেও রুট যদি এখনো মৃত পথেই দেখায়, সমস্যা রুট ইনস্টলেশনে এবং আরেকটি লাইভনেস সমন্বয় কেবল অস্থিরতা যোগ করে।

বিকল্পটি আগে থেকেই ব্যবহারযোগ্য হতে হবে

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

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

ফেইলব্যাক অস্থিরতা ও ব্যবস্থাপনা পথ

প্রাইমারি পুনরুদ্ধার করা একটি আলাদা সিদ্ধান্ত। আক্রমনাত্মক ফেইলব্যাক এমন কাজ বাধাগ্রস্ত করতে পারে যা ইতিমধ্যে ব্যাকআপে পুনরুদ্ধার হয়েছে, আর দোলায়মান পথকে অস্থির টানেল মনে হতে পারে যখন আসল ত্রুটি হলো দুটি সমান বিকল্পের মধ্যে ক্রমাগত দোলা দেওয়া একটি রুট।

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

তারপর একই কাজের চাপ পুনরাবৃত্তি করুন এবং একই চারটি টাইমস্ট্যাম্প তুলনা করুন। সংক্ষিপ্ত পুনরুদ্ধার যা এখনো অ্যাপ্লিকেশনকে একই অনুপস্থিত রুট বা লগইনের জন্য অপেক্ষা করায়, তা অগ্রগতি নয়, একই গ্রাফে ভিন্ন একটি সংখ্যা।