MTU নাকি MSS? VPN-এর একটি পরিবর্তন আসলে কী ঠিক করে

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

দুটি সংখ্যা, দুটি বস্তু

MTU একটি লিঙ্ক বা ইন্টারফেসের অন্তর্গত: এটি হলো সেই বৃহত্তম প্যাকেট যা না ভেঙে পার করা যায়। MSS হলো TCP-র অন্তর্গত: এটি একটি সেগমেন্ট যে সর্বোচ্চ পরিমাণ TCP পেলোড বহন করতে পারে, এবং এটি TCP ও IP দুটো হেডারই বাদ দেয়। IPv4 চালু থাকা একটি সাধারণ ইথারনেট লিঙ্কে 1500 বাইটের MTU পরিচিত 1460 বাইটের MSS দেয়। এই সংখ্যাগুলো ভিন্ন স্তর বর্ণনা করে এবং ভিন্ন প্রক্রিয়ায় বিনিময় হয়। এগুলো গুলিয়ে ফেলা সহজ, কারণ দুটোই বাইটে মাপা হয় এবং দুটোই 1500-এর কাছাকাছি।

একটি আসে ইন্টারফেস সেটিং হিসেবে। অন্যটি আসে একটি SYN সেগমেন্টের ভেতরে অপশন হিসেবে, যা এমন প্রান্তের মধ্যে দরকষাকষি হয় যারা আপনার ইন্টারফেস কখনও দেখে না।

বাইরের অতিরিক্ত ভার কোথায় পড়ে

VPN ভেতরের প্যাকেটকে আরেকটির ভেতরে রাখে, এবং বাইরের প্যাকেটকে ভৌত পথে ফিট হতে হয়। এনক্যাপসুলেশন হেডার, বাইরের IP হেডার, ট্রান্সপোর্ট হেডার এবং যেকোনো প্রমাণীকরণ ট্যাগ—সবই এমন বাইট খরচ করে যা ভেতরের প্যাকেট ব্যবহার করতে পারে না। টানেল ইন্টারফেস 1500-এ রেখে দিলে বাইরের প্যাকেট নিয়মিতই পথ যতটা বহন করতে পারে তার বেশি হয়ে যায়। 'ফ্র্যাগমেন্ট নয়' বিট বসানো থাকলে রাউটার এটি ফেলে দেয় এবং একটি ICMP ত্রুটি ফেরত পাঠানোর কথা; সেই ত্রুটি ফিল্টার হলে প্রেরক কখনও জানে না।

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

MSS সীমিত করা, এবং কোথায় প্রযোজ্য

MSS ক্ল্যাম্পিং একটি নির্বাচিত বিন্দু অতিক্রম করার সময় SYN সেগমেন্টের মানটি পুনর্লিখন করে, ফলে দুই প্রান্তই কারণ না জেনে ছোট পেলোড বেছে নেয়। লিনাক্সে এটি একটি mangle টেবিলের লক্ষ্য যা স্পষ্ট নিয়মে প্রয়োগ হয়, এবং আপনি যে দিকে চান সেই দিকে SYN প্যাকেটে আঘাত করতে হবে। এটিকে টানেল ইন্টারফেস ও ঠিকানার পরিসরে সীমাবদ্ধ করুন, কারণ বিস্তৃত নিয়ম এমন ট্রাফিকের আচরণ বদলে দেয় যা কখনও টানেলে ঢোকে না।

প্রভাব কেবল TCP-তে। একটি UDP অ্যাপ্লিকেশন, একটি QUIC সেশন এবং নিজস্ব ডেটাগ্রাম তৈরি করে এমন যেকোনো প্রোটোকল এটি দ্বারা অক্ষত থাকে।

নির্দিষ্ট পথে নির্ণয় করুন

একবারে একটি চলক রাখুন। আপনি যে আকার বেছে নেন এমন প্যাকেট দিয়ে পরীক্ষা করুন, এবং 'ফ্র্যাগমেন্ট নয়' ফ্ল্যাগ সেট করুন যাতে কার্নেল ফলাফল লুকানোর বদলে জানায়।

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

প্রতিটি পরিবর্তন কী ঠিক করে না

ইন্টারফেসের MTU কমানো আগেই প্রতিষ্ঠিত একটি সেশনের MSS বদলায় না। MSS সীমিত করা UDP প্রবাহে সাহায্য করে না, আর যে পথে ICMP ত্রুটি কেবল এক দিকেই ফিল্টার হয় সেই পথ মেরামত করে না। প্রতিটি পরিবর্তন এক শ্রেণির সমস্যা ঠিক করে এবং বাকিগুলো ঠিক যেমন ছিল তেমনই রেখে দেয়।

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