ক্যাপচারে নতুন IKE_SA_INIT বিনিময় কীভাবে পড়বেন

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

প্রথমে নিশ্চিত করুন ক্যাপচার শুরু থেকেই শুরু হয়েছে

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

ক্যাপচারটিকে দুটি প্রান্তবিন্দু এবং UDP 500 ও 4500-এ সীমাবদ্ধ করুন যাতে ফাইলটি পড়ার মতো ছোট থাকে। ব্যস্ত হোস্টে ফিল্টারহীন ক্যাপচার দর-কষাকষিকে অসম্পর্কিত ট্রাফিকের নিচে চাপা দেয়।

tcpdump -i any -n -s 0 -w fresh-ike.pcap 'udp port 500 or udp port 4500'

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

দ্বিতীয়ে, পেলোডের আগে হেডার পড়ুন

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

এই প্রথম বিনিময়ে প্রস্তাব, কী বিনিময় ও নন্স পেলোড খোলাখুলিই পাঠযোগ্য। পাঠযোগ্য মানে প্রমাণিত নয়, আর এই পর্যায়ে কোনও পক্ষই নিজের পরিচয় প্রমাণ করেনি।

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

তৃতীয়ে, অনুরোধের সঙ্গে তার উত্তর মেলান

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

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

দিকও গুরুত্বপূর্ণ। উত্তরহীন অনুরোধ আর যে উত্তর কখনও ক্লায়েন্টে পৌঁছায় না তা ভিন্ন ত্রুটি, এবং কেবল দ্বিতীয়টিই ক্লায়েন্ট-দিকের টাইমআউটের মতো দেখায়।

চতুর্থে, 4500-এ IKE-কে বাকি সবকিছু থেকে আলাদা করুন

4500 পোর্টে তিনটি জিনিস থাকে যা সারসংক্ষেপে একই রকম দেখায়: চার-বাইট শূন্য non-ESP মার্কারের পিছনে IKE, এনক্যাপসুলেটেড ESP যার মার্কারের জায়গায় অশূন্য SPI থাকে, এবং ছোট কীপঅ্যালাইভ। ওই মার্কারই IKE-কে এনক্যাপসুলেটেড ESP থেকে আলাদা করে, তাই ট্রাফিককে IKE নাম দেওয়ার আগে ওই বাইটগুলো পড়ুন। 4500 পড়া ক্যাপচার লেবেল একটি পোর্ট নম্বর, প্রোটোকল নয়।

এনক্যাপসুলেটেড ESP হলো এনক্রিপ্টেড পেলোড যা কী ছাড়া ব্যাখ্যা করা যায় না, আর এর উপস্থিতি ত্রুটির বদলে কাজ করা টানেলের চিহ্ন হতে পারে।

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

একটি পর্যবেক্ষণ বিন্দুতে নীরবতার অর্থ

ক্লায়েন্টে উত্তর না থাকা কেবল ওই বিন্দু যা দেখেছে তা-ই প্রমাণ করে। ফিল্টারিং, রাউটিং, ভুল দূরবর্তী ঠিকানা, বন্ধ সেবা এবং প্রোটোকল অমিল—সবই একই ফাঁকা ট্রেস তৈরি করে।

প্রাসঙ্গিক ICMP unreachable প্রমাণ যোগ করে, তবে তার ভিতরের উদ্ধৃত প্যাকেটটি পড়ুন এবং যে ডিভাইস পাঠিয়েছে তার ঠিকানা লিখে রাখুন।

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