ডুপ্লিকেট IKE প্যাকেট: হারানো ট্রানজিশন খুঁজুন

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

ভ্রান্ত ধারণা: পুনরাবৃত্ত অনুরোধ এক লিংকে ক্ষতি প্রমাণ করে

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

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

পুনঃপ্রেরণ আসলে আপনাকে কী বলে

IKEv2-তে পুনঃপ্রেরণ এভাবে কাজ করে: কোনো উত্তর না এলে অনুরোধকারী অনুরোধ পুনরাবৃত্তি করে, আর উত্তরদাতা নতুন হিসাব না করে তার ক্যাশে করা উত্তর আবার পাঠাতে পারে। বার্তা শনাক্তকারী সেই এক্সচেঞ্জের অন্তর্গত, এবং এজন্যই একই শনাক্তকারীযুক্ত পুনরাবৃত্ত অনুরোধ নতুন প্রচেষ্টা নয় বরং প্রোটোকলের কাজ হিসেবে চেনা যায়। প্রাথমিক প্রচেষ্টায় সম্পর্ক জোড়া লাগাতে প্রায়ই কেবল সোর্স অ্যাড্রেস বা ইনিশিয়েটর SPI যথেষ্ট হয় না, তাই প্ল্যাটফর্মের নিজের এক্সচেঞ্জ রেকর্ড প্যাকেট তালিকার চেয়ে ভালো। IKEv1 ভিন্ন শনাক্তকারীসহ ভিন্ন নিয়ম অনুসরণ করে, আর প্রথম প্যাকেট ডুপ্লিকেট নিয়ে ভেন্ডর সতর্কবার্তার অর্থ সব ভার্সনে এক নয়।

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

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

এক শৃঙ্খল হিসেবে চারটি পর্যবেক্ষণ বিন্দু

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

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

প্রথম অনুপস্থিত ট্রানজিশন খুঁজুন

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

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

tcpdump -ni any -vv 'udp port 500 or udp port 4500'

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

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

একটি কাজে লাগার মতো প্রতিবেদন কী বলে

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

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

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