VPN MTU-র ভ্রান্ত ধারণা: আপনার প্যাকেট কেন ছোট হয় আর জায়গা কোথায় যায়

কেউ আপনাকে বলে VPN "MTU-র কারণে প্যাকেট হারাচ্ছে", আপনি টানেল 1400-এ সেট করেন, আর ট্রান্সফার আবার কাজ করে। এই ফলাফলকে রোগনির্ণয় মনে হয়। এটি সাধারণত পাটিগণিতের কাকতালীয় মিল: আপনি এমন ছোট একটি সংখ্যা বেছেছেন যা আপনি কখনো শনাক্ত করেননি এমন একটি সীমার নিচে ফিট করে, আর পরের নেটওয়ার্কে ভিন্ন বাজেট নিয়ে আবার সেই সীমার মুখোমুখি হবেন।

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

প্রথম ভ্রান্ত ধারণা: টানেলের MTU-ই পথের MTU

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

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

দ্বিতীয় ভ্রান্ত ধারণা: এনক্যাপসুলেশনের খরচ একটি হেডার

বাইরের স্তরগুলো সৎভাবে গুনুন। বাইরের IP হেডার IPv4-এ 20 বাইট বা IPv6-এ 40। NAT ট্রাভার্সালের জন্য UDP এনক্যাপসুলেশন 8 যোগ করে। টানেল প্রোটোকল যোগ করে নিজের হেডার, একটি ইনিশিয়ালাইজেশন ভেক্টর বা nonce, সাইফারের ব্লক বা অ্যালাইনমেন্ট সীমানা পর্যন্ত প্যাডিং, একটি ট্রেইলার আর একটি ইন্টিগ্রিটি চেক মান। প্রোটোকল ও সাইফার অনুযায়ী, ভেতরের প্যাকেট শুরুর আগেই মোট সহজে কয়েক ডজন বাইটে পৌঁছে যায়।

তারপর ভেতরের প্যাকেটের নিজের হেডারগুলোর জন্য আবার বিয়োগ করুন। টানেলের ভেতরের TCP সেগমেন্ট বহন করে নিজের 20 বাইটের IP হেডার ও 20 বাইটের TCP হেডার, আর TCP-র MSS আসে MTU থেকে, টানেলের নামমাত্র পেলোড থেকে নয়। এজন্য ping ছোট পেলোডে সফল হতে পারে অথচ ফাইল ট্রান্সফার আটকে যায়: দুটি টুল ভিন্ন জিনিস পরীক্ষা করে, আর তাদের একটিই পূর্ণ আকারের TCP সেগমেন্ট চালায়।

ip link show tun0
ping -M do -s 1472 192.0.2.10
ping -M do -s 1400 192.0.2.10

প্রথম কমান্ডটি সেট করা টানেল MTU দেখায়। দুটি প্রোব 1472 বাইটের পেলোড পাঠায়, যা IPv4 ও ICMP হেডারের 28 বাইটসহ 1500 বাইটের প্যাকেট, তারপর আরও ছোট একটি। বড় প্রোব সম্পূর্ণ ব্যর্থ হয়ে ছোটটি সফল হলে আপনার সমস্যা আকার-নির্ভর, সাধারণ রাউটিং সমস্যা নয়।

তৃতীয় ভ্রান্ত ধারণা: PPPoE এখনো আপনাকে পরিচ্ছন্ন 1500 দেয়

প্রচলিত PPPoE অ্যাক্সেস লিঙ্ক 1500 বাইটের IP প্যাকেট বহন করে না। PPPoE হেডার আর PPP প্রোটোকল ফিল্ড ইথারনেট ফ্রেমের ভেতরে 8 বাইট নেয়, ফলে IP প্যাকেটের জন্য থাকে 1492। এটি RFC 2516-এ বর্ণিত প্রচলিত সীমা। এমন লিঙ্কের উপরে VPN চালালে টানেলের ওভারহেড আসে সেই 1492 থেকে, 1500 থেকে নয়।

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

ব্যর্থতাটি কেন বাছাইকৃত মনে হয়

ছোট অনুরোধ সফল হওয়া আর বড় ট্রান্সফার আটকে যাওয়া পথ-MTU ব্ল্যাক হোলের চিরচেনা চিহ্ন। হ্যান্ডশেক, DNS কোয়েরি আর API কল সবই ফিট করে; বাল্ক ট্রান্সফার পূর্ণ আকারের সেগমেন্ট তৈরি করে যা একটি লিঙ্কে মারা যায়, আর সমস্যা জানানোর কথা থাকা ICMP বার্তাটি কখনো আসে না। সংযোগ ঠিক দেখায় আর ডাউনলোড ঝুলে থাকে, ফলে মানুষ পথের বদলে সার্ভারের দিকে তাকায়।

দ্বিতীয়, সম্পর্কিত ভুল হলো তিনটি সংখ্যা গুলিয়ে ফেলা: ইন্টারফেস MTU, TCP MSS আর প্রোটোকলের নিজস্ব ফ্র্যাগমেন্টেশন বা প্যাডিং সেটিং। রাউটারে MSS ক্ল্যাম্পিং বিজ্ঞাপিত MSS পুনর্লিখন করে যাতে প্রেরক ছোট সেগমেন্ট বানায়; এটি টানেল MTU বদলায় না, আর UDP ট্রাফিকে সাহায্য করে না। সম্পর্কিত দেখায় বলে তিনটিকেই একই সংখ্যা দেওয়া—এভাবেই ভালো উদ্দেশ্যের পরিবর্তনে কাজ করা সেটআপ ভেঙে যায়।

কী বদলাবেন, কোন ক্রমে

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

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