প্যাকেট ক্যাপচারে প্রথম IKEv2 বিনিময় কীভাবে পড়বেন
SPI ও মেসেজ আইডি দিয়ে IKE_SA_INIT অনুরোধ ও উত্তর মেলান, 4500-এ IKE-কে এনক্যাপসুলেটেড ESP থেকে আলাদা করুন এবং একটি নীরব ট্রেস কী প্রমাণ করতে পারে তা দেখুন।
সেশনের মাঝখানে নেওয়া ক্যাপচারই সাধারণত IKEv2 ট্রেসকে কোলাহলের মতো দেখায়, কারণ রেকর্ডিং শুরু হওয়ার সময় দুই পক্ষ ইতিমধ্যে কী পুনর্নবীকরণ বা এনক্রিপ্টেড পেলোড বিনিময় করছে। বরং একটি নতুন সংযোগ প্রচেষ্টা থেকে শুরু করুন, যাতে ফাইলের প্রথম বার্তাটিই হয় সেই বার্তা যা দরকষাকষি শুরু করে। নিচের পাঠক্রম সেটাই ধরে নেয় এবং সেই বিন্দুটি চিহ্নিত করে যেখানে একটি প্যাকেট দূর প্রান্ত সম্পর্কে আর কিছুই প্রমাণ করে না। এই ধাপটি বাদ দেওয়ার কারণেই একটি কাজ করা টানেলকে ব্লক করা পোর্ট হিসেবে রূপ নির্ণয় করা হয়।
নিশ্চিত করুন যে আপনি সূচনা বিনিময় দেখছেন
একটি IKEv2 দরকষাকষি শুরু হয় IKE_SA_INIT দিয়ে, বিনিময় ধরন 34, মেসেজ আইডি 0। সূচনাকারী একটি অশূন্য SPI বেছে নেয়, আর সেই প্রথম অনুরোধে উত্তরদাতার SPI শূন্য এবং উত্তরে অশূন্য। এই তিনটি তথ্য নতুন একটি প্রচেষ্টাকে কী পুনর্নবীকরণ বা ক্যাপচারের শীর্ষে থাকা একটি IKE_AUTH বার্তা থেকে আলাদা করে।
হেডার ক্ষেত্রগুলি পাঠযোগ্য, এবং প্রস্তাব, কী বিনিময় ও nonce পেলোডও তাই। পাঠযোগ্য মানে প্রমাণিত নয়: এই পর্যায়ে কোনো পক্ষই পরিচয় প্রমাণ করেনি, এবং Diffie-Hellman-এর ব্যক্তিগত মান তারে কখনও দেখা যায় না।
ডিকোড প্যানেল স্ক্রল করার বদলে ক্ষেত্রগুলি টেবিল হিসেবে ছাপুন, কারণ পুনঃপ্রেরণ ও অমিল SPI কলামে স্পষ্ট হয়ে যায়।
tshark -r ike.pcapng -Y "isakmp" -T fields -e frame.number -e ip.src -e udp.srcport -e isakmp.exchangetype -e isakmp.messageid -e isakmp.initiator_spi -e isakmp.responder_spi
আউটপুট জোড়ায় জোড়ায় পড়ুন। মেসেজ আইডি 0 সহ একটি অনুরোধের পরে একই আইডি ও অশূন্য উত্তরদাতা SPI বহনকারী একটি উত্তর হলো একটি বিনিময়, যদিও অনুরোধ পুনঃপ্রেরিত হওয়ায় এটি তিনবার দেখা যায়। তিনটি অভিন্ন অনুরোধ তিনটি লগইন নয়, আর সেভাবে ধরে নিলেই মানুষ সিদ্ধান্তে আসে যে ক্লায়েন্ট লুপে ঘুরছে, অথচ সে কেবল ধৈর্যশীল। মেসেজ আইডি অনুসারে, তারপর সময়চিহ্ন অনুসারে সাজান, আর পুরো কথোপকথন সংক্ষিপ্ত প্রচেষ্টার তালিকায় সংকুচিত হবে।
সাফল্য পড়ার আগে প্রত্যাখ্যান পড়ুন
উত্তর মানেই স্বয়ংক্রিয় অগ্রগতি নয়। উত্তরদাতা cookie বিজ্ঞপ্তি দিয়ে উত্তর দিয়ে সূচনাকারীকে আবার চেষ্টা করতে বলতে পারে, বা এমন একটি গ্রুপের নাম দেওয়া INVALID_KE_PAYLOAD দিতে পারে যা সে বরং গ্রহণ করবে। দুটোই সঠিকভাবে গঠিত IKE বার্তা হিসেবে আসে, আর কেবল প্যাকেট গোনা ফিল্টারের কাছে দুটোই সম্পূর্ণ বিনিময়ের মতো দেখায়।
বিজ্ঞপ্তি পেলোড খুলে সবার আগে ধরনটি পড়ুন। cookie চ্যালেঞ্জ মানে উত্তরদাতা জাল করা উৎস ঠিকানা থেকে নিজেকে রক্ষা করছে, এবং ক্লায়েন্টকে cookie সংযুক্ত করে আবার পাঠাতে হবে। অবৈধ গ্রুপ মানে দুটি প্রস্তাব একমত নয়, যা এক পক্ষের কনফিগারেশন না বদলানো পর্যন্ত কোনো পুনঃচেষ্টায় বদলাবে না।
কেবল IKE_AUTH, দ্বিতীয় বিনিময়, এনক্রিপ্টেড পরিচয় ও প্রমাণীকরণ পেলোড বহন করে। তাই সম্পূর্ণ IKE_SA_INIT আপনাকে বলে যে দুই পক্ষ অ্যালগরিদম ও উদ্ভূত কী নিয়ে একমত, আর শংসাপত্র গ্রহণ করা হবে কি না সে সম্পর্কে কিছুই না। সেখানেও দুটি বার্তা আশা করুন, এবং সেশন কী ছাড়া দুটোই অস্বচ্ছ থাকবে বলে আশা করুন।
পোর্ট 4500 একক প্রোটোকল নয়
UDP 500 সাধারণত সূচনা বিনিময় বহন করে। NAT সনাক্তকরণ চালু হওয়ার পরে IKE 4500-এ চলে যায় এবং প্রতিটি বার্তার আগে চার বাইটের শূন্য অ-ESP চিহ্ন বসায়। একই পোর্টে এনক্যাপসুলেটেড ESP বরং অশূন্য ESP SPI দিয়ে শুরু হয়, আর এক বাইটের NAT keepalive হলো তৃতীয় আকৃতি যা অন্য কিছু না ঘটলে দেখা যায়।
কেবল পোর্ট মেলানো ফিল্টার তিনটিই মিশিয়ে দেয়, তাই "4500-এ ট্রাফিক আছে" খুব কম কিছু স্থির করে। দূর প্রান্ত সম্পর্কে সিদ্ধান্তে আসার আগে প্রোটোকল অনুসারে দৃশ্যটি ভাগ করুন।
tshark -r ike.pcapng -Y "udp.port == 4500 && isakmp" -T fields -e frame.number -e isakmp.exchangetype tshark -r ike.pcapng -Y "udp.port == 4500 && !isakmp" -T fields -e frame.number -e esp.spi
নীরবতা পর্যবেক্ষণ বিন্দুকে বর্ণনা করে
উত্তরহীন অনুরোধ ঠিক একটি জিনিস প্রমাণ করে: সেই ক্যাপচার বিন্দুতে কোনো উত্তর আসেনি। ফিল্টারিং, উত্তর অন্যত্র পাঠানো রুট, পৌঁছানো যায় না এমন উত্তরদাতা, বা প্রস্তাব পছন্দ করে না এমন উত্তরদাতা—সবাই একই শূন্য ফল দেয়, আর সাধারণ UDP প্রোব তাদের আলাদা করবে না।
ICMP অপ্রাপ্যতা অন্য ধরনের প্রমাণ। এর ভিতরে উদ্ধৃত প্যাকেটটি পড়ুন এবং কোন ডিভাইস এটি ছেড়েছে তা শনাক্ত করুন, কারণ রাউটারের প্রশাসনিক প্রত্যাখ্যান দূর প্রান্তের প্রমাণিত ত্রুটি নয়।
tshark -r ike.pcapng -Y "icmp.type == 3" -T fields -e frame.number -e ip.src -e icmp.code
যেখানে পড়ার অনুমতি আছে সেখানে একই প্রচেষ্টাকে সার্ভার-পক্ষের লগের সঙ্গে মিলিয়ে দেখুন। অনুরোধটি পৌঁছেছিল কি, সেবাটি উত্তর দিয়েছিল কি, আর উত্তরটি কোথায় থেমেছিল? এই তিনটি উত্তর আপনাকে পথের সমস্যা বা নীতির সমস্যায় পাঠায়, আর সেগুলো চতুর্থবার শংসাপত্র ঘোরানোর চেয়ে কম খরচে পড়ে।