সার্টিফিকেট চেইনের সমস্যা থেকে IKEv2 ফ্র্যাগমেন্টেশন আলাদা করা

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

দুটি ফ্র্যাগমেন্টেশন প্রক্রিয়া, একটি উপসর্গ

IKEv2-এর নিজস্ব ফ্র্যাগমেন্টেশন এক্সটেনশন আছে, যা RFC 7383-এ সংজ্ঞায়িত এবং সুরক্ষিত IKE বার্তাগুলোকে ছোট IKE বার্তায় ভাগ করে। দুই পক্ষ সেই সামর্থ্য নিয়ে দরকষাকষি করে, আর বার্তাটি IP স্তর নয়, IKE বাস্তবায়নই পুনরায় জোড়া দেয়।

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

NAT ট্রাভার্সাল তৃতীয় একটি চলক যোগ করে, কারণ তখন ESP UDP-তে মুড়ে দেওয়া হয় এবং বাইরের প্যাকেট বড় হয়ে যায় অথচ পোর্ট 4500-এ সাধারণ UDP ট্রাফিকের মতো দেখায়। UDP ভালোভাবে পার হওয়া পথও এমন ডেটাগ্রামে ব্যর্থ হতে পারে যা আর ধরে না।

ব্যর্থ বিনিময়টি পড়ুন

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

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

পথ বদলান, সার্টিফিকেট নয়

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

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

কিছু সম্পাদনার আগে বিনিময়টি মাপুন

চেইনের আকার ও পথের আকার বের করুন। দুটি সংখ্যাই হ্যান্ডশেক কী পাঠাতে পারে তা সীমাবদ্ধ করে, আর দুটিই মাপা সস্তা:

openssl crl2pkcs7 -nocrl -certfile chain.pem | openssl pkcs7 -print_certs -noout | grep -c subject
ls -l chain.pem
ping -M do -s 1400 198.51.100.7
ip -s link show eth0 | sed -n '1,6p'

প্রথম দুটি সার্টিফিকেটের সংখ্যা ও ফাইলের আকার দেয়, যা প্রমাণীকরণ বার্তা কত বড় হবে তার যুক্তিসঙ্গত সূচক। ping পরীক্ষা জানায় ওই আকারের ডেটাগ্রাম পথ পার হয় কি না, আর ইন্টারফেস কাউন্টার দেখায় আপনার প্রান্তে ফ্র্যাগমেন্ট ফেলা হয়েছে কি না। Windows-এ সমতুল্য পরীক্ষা হলো do-not-fragment ফ্ল্যাগ ও স্পষ্ট পেলোড আকারসহ ping।

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

যে স্তরটি সত্যিই ভাঙা সেটিই সারান

পথটি বড় ডেটাগ্রাম ফেলে দিলে দুই পক্ষেই IKE ফ্র্যাগমেন্টেশন চালু করুন এবং এক্সটেনশনটি শুধু প্রস্তাবিত নয়, দরকষাকষি করা হয়েছে তা নিশ্চিত করুন। পথটি IP স্তরে ফ্র্যাগমেন্ট খারাপভাবে সামলালে সমাধান সেখানেই বা বাইরের ইন্টারফেসের MTU-তে, সার্টিফিকেট ভাণ্ডারে নয়।

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

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