IKEv2-এ ডেড পিয়ার ডিটেকশন আপনার অ্যাপ পরীক্ষা করে না
লাইভনেস চেক পিয়ার সম্পর্ক পরীক্ষা করে, কোনো ওয়েবসাইটের প্রতিক্রিয়ার সময় নয়। যে গেটওয়ে উত্তর দেয়, সেটি ভাঙা অ্যাপ্লিকেশন রুটের পাশে থাকতে পারে।
IKEv2-এর লাইভনেস চেক একটি প্রশ্ন করে: সুরক্ষিত নিয়ন্ত্রণ সম্পর্কে অন্য পিয়ারটি কি এখনও উত্তর দিচ্ছে। এটি মাপে না অভ্যন্তরীণ অ্যাপ্লিকেশন সুস্থ কি না, গেটওয়ের পেছনে কোনো রুট আছে কি না, বা ব্রাউজিং দ্রুত মনে হয় কি না। চেক পাস হতে পারে, অথচ টানেলের পেছনের প্রতিটি কাজের জিনিস ব্যর্থ হচ্ছে।
টাইমার বদলানোর আগে দুই ধরনের প্রমাণ আলাদা করে পড়ুন।
লাইভনেস চেক আসলে কী জিজ্ঞাসা করে
একটি লাইভনেস বিনিময় প্রতিষ্ঠিত IKE সিকিউরিটি অ্যাসোসিয়েশনের ভিতরে পাঠানো হয় এবং নির্ধারিত উইন্ডোর মধ্যে উত্তর আশা করে। সফল মানে পিয়ারের IKE বাস্তবায়ন এখনও আছে এবং এখনও কথা বলতে রাজি। এটি ট্রাফিক বহনকারী চাইল্ড সিকিউরিটি অ্যাসোসিয়েশন সম্পর্কে কিছু বলে না, গেটওয়ের ওপারের রাউটিং সম্পর্কে কিছু বলে না, এবং যে সেবার জন্য আপনি টানেল খুলেছেন তা সম্পর্কেও কিছু বলে না। এগুলো তিনটি আলাদা প্রশ্ন, তিনটি আলাদা ব্যর্থতার ধরন।
এই পার্থক্যই ঠিক করে সেশন চুপ হলে আপনি কোথায় দেখবেন। ডেটা পথ ভাঙা থাকলেও যে পিয়ার উত্তর দিতে থাকে, সে নীতি, রাউটিং বা ডাউনস্ট্রিম সেবার দিকে ইঙ্গিত করে। যে পিয়ার উত্তর দেওয়া বন্ধ করে, সে পৌঁছানোর ক্ষমতা বা দূর প্রান্তের নিজের অবস্থার দিকে ইঙ্গিত করে।
ব্রাউজারের আগে সিকিউরিটি অ্যাসোসিয়েশন পড়ুন
ডেমনকে জিজ্ঞাসা করলেই নিয়ন্ত্রণ অবস্থা ও ডেটা অবস্থা আলাদাভাবে তালিকাভুক্ত হয়, আর কাউন্টার বলে দেয় আদৌ কিছু চেষ্টা করা হয়েছিল কি না। যে চাইল্ড অ্যাসোসিয়েশন কখনও ইনস্টল হয়নি, সেটি ইনস্টল হয়ে পরে প্যাকেট পাঠানো বন্ধ করা অ্যাসোসিয়েশনের মতো একেবারেই দেখায় না, যদিও দুটোই একই ব্যবহারকারী অভিযোগ তৈরি করে।
ipsec statusall | head -n 40
swanctl --list-sas
ip xfrm state | grep -E 'proto|mode'
টিকিটে অবস্থার নামগুলো হুবহু লিখুন, অভিযোগের মুহূর্তের কাউন্টারসহ। টানেল ডাউন-এর মতো বর্ণনা লুকিয়ে রাখে দুটি অ্যাসোসিয়েশনের কোনটি শেষ হয়েছে, আর সাধারণত সেটাই একমাত্র তথ্য যা রাখার যোগ্য।
রুট ব্যর্থতা দেখতে হুবহু মৃত পিয়ারের মতো
গেটওয়ে নিয়ন্ত্রণ বিনিময়ের উত্তর দিতে পারে, অথচ একটি ব্যক্তিগত সার্ভার অফলাইন, একটি ফরওয়ার্ড করা রুট অনুপস্থিত, বা অভ্যন্তরীণ নাম রিজলিউশন পুরোপুরি ব্যর্থ। ক্লায়েন্টের দিক থেকে এগুলোর প্রত্যেকটি এমন সেশন দেখায় যা চালু আছে আর গন্তব্য যা নেই। ফিরতি পথটিও সমান মনোযোগে পরীক্ষা করুন, কারণ দূর প্রান্তে অসমমিত রাউটিং কেবল এক দিকেই নীরবতা তৈরি করে।
টানেল চালু আছে কি না তা পরীক্ষা করার বদলে উদ্দিষ্ট অ্যাপ্লিকেশনটি সরাসরি পরীক্ষা করুন এবং এটি যে ঠিকানায় চেষ্টা করেছে তা লিখুন। গেটওয়েতে পিং প্রমাণ করে গেটওয়ে উত্তর দেয়; এটি কখনও প্রমাণ করেনি অ্যাপ্লিকেশন উত্তর দিয়েছে। অ্যাপ্লিকেশন যে সঠিক ঠিকানায় চেষ্টা করেছে তা লিখে রাখুন। ওই স্ট্রিং পরে অনুসন্ধান সংকুচিত করে, আর টিকিট সাধারণত এই একটি তথ্যই বাদ দেয়।
টাইমারকে ডায়াগনোসিসের বাইরে রাখুন
ডিটেকশন ইন্টারভাল কমানো কোনো পারফরম্যান্স পরিবর্তন নয় এবং ধারণক্ষমতা বাড়ায় না। প্যাকেট লসের সময় এটি বদলে দেয় ব্যর্থতা কত দ্রুত চেনা যায়, যা কিছু ভালো না করেও উপসর্গকে ভিন্ন দেখাতে পারে। আগে ব্যর্থতার প্রকৃত সময় লিখুন, তারপর ঠিক করুন আপনার সত্যিকারের লিংকের জন্য সহনশীলতা ভুল কি না।
NAT ম্যাপিং রিফ্রেশও একই শ্রেণিতে পড়ে। এগুলো অনূদিত পথটি ব্যবহারযোগ্য রাখে, এবং দূরবর্তী অ্যাপ্লিকেশন কাজ করছে এর প্রমাণ নয়।
একটি সম্পূর্ণ পুনরুদ্ধার নীতি বলে দেয় পিয়ার মৃত ঘোষণা হলে ক্লায়েন্টের কী করা উচিত: পুনরায় চালু, বন্ধ, বা ধরে রাখা, এবং তখন অন্য ট্রাফিক কী করতে পারে। তা ছাড়া একই ঘটনা প্রতি ত্রৈমাসিকে শূন্য থেকে আবার নির্ণয় করা হয়।