MTU কালো গহ্বর: ছোট অনুরোধ কেন কাজ করে কিন্তু আপলোড আটকে যায়
ছোট অনুরোধ শেষ হয়, অথচ বড় আপলোড চিরকাল ঝুলে থাকে, আর প্রেরক কখনো জানে না যে পথটি সরু। যে নির্দিষ্ট আকারে এটি ভাঙে, তা মাপুন।
একটি পৃষ্ঠা লোড হয়, একটি ছোট API কল ফিরে আসে, তারপর একটি ফাইল আপলোড ক্লায়েন্ট হার মানা পর্যন্ত ঝুলে থাকে। সার্ভার লগে কিছুই এটি ব্যাখ্যা করে না, কারণ প্যাকেটগুলি পথের মাঝখানে ফেলে দেওয়া হয়েছে, কোনো কাজের উত্তর ফেরত না দিয়েই। এই ধরনের প্যাটার্ন হলো MTU কালো গহ্বর: প্রেরকের ধারণার চেয়ে সরু একটি লিঙ্ক, সাথে এটি না বলার নীরব অস্বীকৃতি। যে আকারে ব্যর্থতা ঘটে তা পুনরাবৃত্তিযোগ্য, আর সেটিই এটিকে নির্ণয়যোগ্য করে তোলে।
কী গহ্বরটিকে কালো করে তোলে
প্রতিটি লিঙ্কের একটি সর্বোচ্চ ট্রান্সমিশন ইউনিট থাকে, আর পরবর্তী হপের সীমার চেয়ে বড় প্যাকেটকে হয় ফ্র্যাগমেন্ট করতে হবে, নয়তো তা বলার জন্য একটি ICMP বার্তা দিয়ে প্রত্যাখ্যান করতে হবে। পাথ MTU ডিসকভারি নির্ভর করে সেই বার্তাটি পৌঁছানো এবং মানা হওয়ার উপর। এটি ফিল্টার করা বা উপেক্ষা করা প্রেরককে এমন একটি প্যাকেট পুনরায় পাঠাতে ছেড়ে দেয় যা কখনোই ফিট হতে পারে না।
এনক্যাপসুলেশন এটি VPN-এর আশেপাশে সাধারণ করে তোলে, কারণ একটি টানেল ইতিমধ্যে ভৌত লিঙ্কের জন্য মাপা একটি প্যাকেটে একটি বাইরের হেডার যোগ করে। ভেতরের প্যাকেটটি 1500 বাইটে বৈধ আর এনক্যাপসুলেট করা প্যাকেটটি নয়, তাই ছোট প্যাকেটগুলি পার হয়ে গেলেও এটি সীমানায় মারা যায়। সম্পূর্ণ হওয়া হ্যান্ডশেক এবং কাজ করা লগইন পৃষ্ঠা কেবল প্রমাণ করে ছোট প্যাকেটগুলি কাজ করে। অ্যাপ্লিকেশন যে সবচেয়ে বড় প্যাকেট পাঠাতে চেষ্টা করে, সেটিই আসল।
যে আকারে এটি ভাঙে তা খুঁজুন
ফ্র্যাগমেন্ট না করার পরীক্ষা দিয়ে পেলোডের আকার বাইনারি সার্চ করুন, টানেলের এক পাশের হোস্ট থেকে অন্য পাশের হোস্টে। যে সবচেয়ে বড় পেলোড সফল হয়, সেটিই আপনার ব্যবহারযোগ্য পাথ MTU থেকে হেডারের ওভারহেড বাদ দেওয়া।
ping -M do -s 1400 -c 2 192.0.2.20
ping -M do -s 1200 -c 2 192.0.2.20
ping -f -l 1372 192.0.2.201472 বাইটের একটি পেলোড পরিষ্কার 1500 বাইটের Ethernet পথে সফল হয়, যখন IPv4 ও ICMP হেডারের 28 বাইট যোগ করা হয়। যখন একই পরীক্ষা টানেল চালু হওয়ার পর কেবল ছোট পেলোডেই সফল হয়, তখন পার্থক্যটি হলো এনক্যাপসুলেশনের ওভারহেড, আর টানেলের সীমানাই সেই জায়গা যেখানে প্রত্যাখ্যান বার্তাটি তৈরি হওয়া উচিত ছিল। সংযোগের আগে ও পরে দুটি সংখ্যাই লিখে রাখুন, কারণ সেই জোড়াই প্রমাণ। অ্যাপ্লিকেশন IPv6 ব্যবহার করলে তার জন্য পরীক্ষাটি পুনরাবৃত্তি করুন, যেহেতু হেডারটি বড় এবং ব্যর্থতার সীমা সরে যায়।
টানেলকে দোষ দেওয়ার আগে প্রমাণ পড়ুন
দূরবর্তী অ্যাপ্লিকেশনের ত্রুটি, যানজট এবং সাধারণ ক্ষতিও আপলোড আটকে দেয়, তাই একটি ব্যর্থ স্থানান্তর কালো গহ্বর চিহ্নিত করে না। এদের আলাদা করে আকারের সম্পর্ক: 1200 বাইটে পুনরাবৃত্ত সফলতা এবং 1400 বাইটে পুনরাবৃত্ত আটকে যাওয়া, একই দিকে, একই এন্ডপয়েন্ট দিয়ে।
উভয় প্রান্তে ক্যাপচার দেখায় বড় প্যাকেটগুলি বেরিয়ে যাচ্ছে এবং কখনো পৌঁছাচ্ছে না, মাঝখানে কোনো প্রত্যাখ্যান ছাড়াই। এটিই সেই মুহূর্ত যেখানে সার্ভারের বদলে সীমানা ডিভাইসের দিকে তাকানো উচিত, কারণ সার্ভার তার প্রকৃতপক্ষে পাওয়া প্রতিটি অনুরোধের উত্তর দিচ্ছে। যানজটও আটকে দেয়, কিন্তু এটি ভিন্ন সময়ে ভিন্ন আকার আটকে দেয়, যা একটি ভিন্ন স্বাক্ষর।
উভয় ট্রান্সপোর্টে মেরামত যাচাই করুন
সমর্থিত মেরামত হলো সীমানাকে প্রকৃত সীমা জানাতে দেওয়া, অথবা সেখানে TCP-এর সর্বোচ্চ সেগমেন্ট আকার আটকে দেওয়া যাতে কোনো অতিরিক্ত বড় সেগমেন্টের চেষ্টা না হয়। নেটওয়ার্কের প্রতিটি MTU কমানো, বা ফায়ারওয়াল বন্ধ করা, উপসর্গটিকে লুকায় এবং এমন একটি কনফিগারেশন রেখে যায় যা পরে কেউ বিচার করতে পারবে না।
ip link show dev tun0
sudo nft list ruleset | grep -i -E 'mtu|mss'
sysctl net.ipv4.tcp_mtu_probing
ping -M do -s 1400 -c 2 192.0.2.20একই আকার পরীক্ষা দিয়ে যাচাই করুন, তারপর যে অ্যাপ্লিকেশনটি ব্যর্থ হয়েছিল তা দিয়ে, এবং একটি দ্বিতীয় প্রোটোকল দেখুন, কারণ UDP অ্যাপ্লিকেশন কখনো TCP-এর সেগমেন্ট-আকার সংশোধন পায় না। টিকিটে মূল মানগুলি রাখুন, কারণ যে মেরামত ফেরানো যায় না তা আরেকটি সমস্যা যা ঘটার অপেক্ষায় থাকে। যদি আকার পরীক্ষা পাস করে আর আপলোড তবুও আটকে যায়, তবে কালো গহ্বরই কারণ ছিল না, এবং পরিবর্তনটি বাড়ানোর বদলে তদন্ত এগিয়ে নেওয়া উচিত।