IPsec-এ বড় প্যাকেট হারিয়ে যায়, ছোট ping কাজ করে

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

প্যাকেট ভাগ করা যায় এমন দুটি জায়গা

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

পার্থক্যটি গুরুত্বপূর্ণ, কারণ ভুল দিকে লক্ষ্য করা সমাধান ব্যর্থতা না সরিয়েই একটি সংখ্যা বদলে দেয়। ইন্টারফেসে প্রত্যাখ্যাত প্যাকেট কখনই বাইরের প্যাকেট হয় না, তাই বাইরের দিকের কোনো সেটিং তা উদ্ধার করতে পারে না।

আকারের সিদ্ধান্ত আসলে কোথায় নেওয়া হয়

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

প্রথমে ইন্টারফেসের মান দেখুন, তারপর বাইরের আচরণ। দুটি সংখ্যা, দুটি স্তর, আর সাধারণত তাদের একটিই দায়ী।

বাইরের বাজেট ভেতরের বাজেট নয়

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

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

IPv6 একটি বিকল্প সরিয়ে দেয়

IPv6 রাউটার ট্রানজিটে ফ্র্যাগমেন্ট করে না, তাই বাইরের প্যাকেট হয় ফিট করে, নয়তো Packet Too Big বার্তা নিয়ে অদৃশ্য হয়ে যায়। সেই বার্তাই একমাত্র প্রতিক্রিয়া চ্যানেল হয়ে দাঁড়ায়, আর তা অবরুদ্ধ করা পরবর্তী প্রতিটি বড় স্থানান্তরের পথ-আবিষ্কার ভেঙে দেয়। IPv4 রাউটার বিট পরিষ্কার থাকলে বড় প্যাকেট ফ্র্যাগমেন্ট করতে পারে, যা ত্রুটিটি অন্য কিছু সেই বিট বসানো পর্যন্ত লুকিয়ে রাখে।

মিশ্র স্ট্যাকে একই টানেল দুই পরিবারের জন্য ভিন্নভাবে আচরণ করতে পারে, তাই IPv4-এর উপর একটি পরীক্ষা IPv6 অভিযোগ নিষ্পত্তি করে না। যে পরীক্ষা এক পরিবারকে ব্যবহার করে, তা উত্তরের অর্ধেক অমাপা রেখে যায়।

TCP সেগমেন্ট নীতি সাধারণ উত্তর নয়

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

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

যে ক্রমে কাজ করবেন

যে সবচেয়ে বড় পেলোড টিকে থাকে তা লিখুন, তারপর ইন্টারফেস MTU, তারপর বাইরের প্যাকেটে do-not-fragment বিট আছে কি না, এবং শেষে ICMP প্রতিক্রিয়া প্রেরকের কাছে পৌঁছায় কি না। এই ক্রম অনুমান না করেই ত্রুটি সংকুচিত করে। প্রতিটি পর্যবেক্ষণ টাইমস্ট্যাম্প ও প্রান্তসহ রাখুন, কারণ পথ বদলালে চারটি সংখ্যাই সরে যায়।

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