VPN-এর মধ্য দিয়ে পাথ MTU আবিষ্কার: মাপ নির্ধারণ ও ICMP ফাঁক

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

পাথ MTU আসলে কী মাপে

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

টানেলের জন্য গুরুত্বপূর্ণ সংখ্যাটি হলো ভেতরের MTU, অর্থাৎ বাইরের পথের অনুমতি থেকে এনক্যাপসুলেশন যা খরচ করে তা বাদ দিয়ে যা থাকে। WireGuard একটি বাইরের IP হেডার ও একটি UDP হেডার যোগ করে; অন্য ট্রান্সপোর্ট নিজেদেরটা যোগ করে। ভেতরের আকার খুব বেশি রাখলে প্রতিটি পূর্ণ-আকারের প্যাকেটের জন্য ফ্র্যাগমেন্টেশন দরকার হবে যা হয়তো কখনোই ঘটবে না।

কেন টানেল ব্যবহারযোগ্য প্যাকেট ছোট করে

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

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

ফিডব্যাক ফিরে এলে তবেই আবিষ্কার কাজ করে

IPv4 আবিষ্কার নির্ভর করে ডোন্ট-ফ্র্যাগমেন্ট বিটের উপর: যে রাউটার প্যাকেট ফরোয়ার্ড করতে পারে না সে পরবর্তী হপের MTU সহ ICMP fragmentation-needed ফেরত দেয়, আর প্রেরক তার অনুমান কমায়। IPv6 বদলে Packet Too Big বার্তা ব্যবহার করে, কারণ রাউটার ট্রানজিটে ফ্র্যাগমেন্ট করে না। দুই ব্যবস্থাই ধরে নেয় বার্তাটি টানেল পেরিয়ে ও ফেরার পথে যেকোনো ফায়ারওয়াল অতিক্রম করে প্রেরকের কাছে ফিরে আসবে। সেই ধারণা ব্যর্থ হলে প্রেরক এমন আকার বারবার চেষ্টা করে যা পথ বহন করতে পারে না।

যে ফায়ারওয়াল echo request ও echo reply অনুমোদন করে সে অবশ্যই সেই ত্রুটি-ধরনগুলো অনুমোদন করেছে না। ICMP একটি পরিবার, আর এখানে গুরুত্বপূর্ণ সদস্য হলো ত্রুটিগুলো, echo জোড়া নয়। টানেলের দুই প্রান্তে ও তাদের মধ্যের পথে কন্ট্রোল-ট্রাফিক নীতি যাচাই করুন, এবং সর্বত্র সব ICMP ধরন অনুমোদনের বদলে প্ল্যাটফর্মের সমর্থিত নির্দেশনা অনুসরণ করুন।

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

সংখ্যা অনুমান না করে পথ পরীক্ষা করুন

গন্তব্য, অ্যাক্সেস নেটওয়ার্ক ও টানেল স্থির রাখুন, তারপর কেবল প্যাকেটের আকার বদলান। MTU ইঙ্গিতসহ ব্যর্থ হওয়া ডোন্ট-ফ্র্যাগমেন্ট প্রোব আপনাকে পরবর্তী হপের সীমা দেয়; কোনো আকার পাস না হওয়া পর্যন্ত পুনরাবৃত্তি করুন, এবং আকার ও ঠিকানা-পরিবার দুটোই লিখে রাখুন।

ping -M do -s 1400 10.60.20.10
ping -M do -s 1300 10.60.20.10
ping -6 -M do -s 1300 2001:db8::10

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

RFC 4821-এ বর্ণিত PLPMTUD উপরের দিকে প্রোব করে এবং প্রদত্ত ত্রুটির উপর ভরসা না করে ট্রান্সপোর্ট স্বীকৃতি ব্যবহার করে। এটি ICMP ফিল্টার করা পথে সাহায্য করে, তবে সাপোর্ট স্ট্যাক ও অ্যাপ্লিকেশনভেদে ভিন্ন। একটি TCP প্রবাহ নিজে থেকে সেরে উঠতে পারে, আর নির্দিষ্ট ডেটাগ্রাম আকারের UDP অ্যাপ্লিকেশন ব্যর্থ হতে থাকে।

একটি মান বেছে নিন এবং যুক্তিটি লিখে রাখুন

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

IPv4 ব্যবস্থাটি RFC 1191-এ বর্ণিত এবং IPv6 প্যাকেটাইজেশন নির্দেশনা RFC 8201-এ; দুটোই নামকরণ করলে পরবর্তী প্রকৌশলীকে অনুমানটি আবার উদ্ভাবন করতে হয় না। আপনি যে আকার বেছেছেন তাতেও স্থানান্তর আটকে থাকলে সংখ্যা কমানো বন্ধ করুন এবং পরের স্তরে তাকান। প্রতিটি আকারে ব্যর্থ হওয়া পথ MTU-র সমস্যা নয়।