PPPoE-তে OpenVPN: link-mtu, tun-mtu নাকি mssfix কমানো উচিত?

Ping উত্তর দেয়, DNS সমাধান হয়, আর পূর্ণ আকারের সেগমেন্ট দরকার এমন প্রতিটি পৃষ্ঠা আটকে যায়। যে আপলিংক নিজের এনক্যাপসুলেশন যোগ করে, সেখানে পথটি নিঃশব্দে কয়েক ডজন বাইট বাজেট হারায়, আর পরিষ্কার Ethernet-এর জন্য লেখা প্রোফাইল এমন প্যাকেট চাইতেই থাকে যা লাইনটি বহন করতে পারে না। সংযোগটি ধীর নয়; এটি ঠিক সেই প্যাকেটগুলোই ফেলে দিচ্ছে যেগুলো গুরুত্বপূর্ণ।

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

তিনটি নব, তিনটি আলাদা স্তর

link-mtu হলো বাইরের বাজেট: এনক্রিপ্টেড পেলোড এবং OpenVPN হেডার, UDP হেডার ও বাইরের IP হেডার। এটি বর্ণনা করে মেশিন থেকে কী বেরোয়, এবং সেজন্যই এটি সেই সংখ্যা যা ভৌত পথ সীমিত করে।

tun-mtu হলো ভেতরের বাজেট: যে ইন্টারফেস আপনার ট্রাফিক দেখে। এটি পথটি যা বহন করতে পারে তার চেয়ে ঠিক টানেল ওভারহেড পরিমাণ বড়, এবং OpenVPN সাধারণত আপনাকে এটি সেট করতে না দিয়ে নিজেই তা নির্ণয় করে।

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

আপনি যদি link-mtu স্পষ্টভাবে সেট করেন, OpenVPN ভেতরের MTU নির্ণয় করতে নিজের ওভারহেড বিয়োগ করে। সেই ওভারহেড কোনো নির্দিষ্ট ধ্রুবক নয়; এটি সাইফার ও প্রমাণীকরণের উপর নির্ভর করে, তাই কোনো ফোরাম পোস্ট থেকে নকল করা মান ভিন্ন প্রোফাইলে ভুল হতে পারে। একসাথে link-mtu ও tun-mtu সেট করলে ক্লায়েন্ট দুটি পরস্পরবিরোধী নির্দেশ পায়।

যেকোনো সংখ্যা বাছার আগে পথটি মাপুন

ভৌত ইন্টারফেস থেকে মাপুন, টানেলের ভেতর থেকে নয়, এবং মনে রাখুন ping পেলোড জানায়, প্যাকেটের আকার নয়। পেলোডকে 1500 বাইটের ফ্রেমের সাথে তুলনা করার আগে IPv4 ও ICMP হেডারের জন্য 28 বাইট যোগ করুন, এবং সহযোগী ভিন্ন সংখ্যা জানালে সেই সংশোধন মনে রাখুন।

Linux ক্লায়েন্টে ping -M do -s 1472 ফ্র্যাগমেন্টেশন নিষিদ্ধ করে এবং প্যাকেট খুব বড় হলে ব্যর্থ হয়। পেলোড কমাতে থাকুন যতক্ষণ না তা পার হয়, তারপর পথের MTU পেতে 28 যোগ করুন। PPPoE 8 বাইট নেয়, তাই DSL-এ 1492 স্বাভাবিক। DS-Lite ও কিছু মোবাইল পথ 40 বা তার বেশি নেয়, আর উত্তরটি সাধারণত নামমাত্র লিংক গতির ইঙ্গিতের চেয়ে কম হয়।

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

আগে TCP ক্ল্যাম্প করুন, পরে টানেল সংকুচিত করুন

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

ক্ষতিগ্রস্ত ট্রাফিক TCP না হলে ভেতরের MTU কমান। একটি UDP পরিষেবা, টানেলের ভেতরের টানেল, বা পূর্ণ আকারের ডেটাগ্রাম পাঠায় এমন অ্যাপ্লিকেশন MSS ক্ল্যাম্পের পরেও ব্যর্থ হতে থাকবে, কারণ কিছুই তার প্যাকেট আকার পুনর্লিখন করে না। সেই ক্ষেত্রে tun-mtu কমান, অথবা link-mtu সেট করে ক্লায়েন্টকে ভেতরের মান নির্ণয় করতে দিন, কিন্তু কখনোই দুটোই নয়।

পুরোনো ফ্র্যাগমেন্টেশন বিকল্পের দিকে হাত বাড়াবেন না। এটি টানেলের ভেতরে প্যাকেট ভাগ করত, ওভারহেড যোগ করত, এবং ভালো কারণেই বাতিল হয়েছে; আধুনিক OpenVPN এর বদলে পথটি সঠিকভাবে বর্ণিত হওয়ার প্রত্যাশা করে।

ছোট প্রোব কেন কাজ করতেই থাকে

DNS কোয়েরি, ICMP ইকো ও TCP হ্যান্ডশেক সবই ব্যর্থ আকারের অনেক নিচে। তাই প্রতিটি দ্রুত পরীক্ষায় টানেল সুস্থ দেখায়, অথচ TLS হ্যান্ডশেক ও HTTP প্রতিক্রিয়া নিঃশব্দে ব্যর্থ হয়। সেই সমন্বয়, কাজ করা traceroute আর প্রথম বড় প্রতিক্রিয়ায় আটকে যাওয়া ব্রাউজার, এটাই খোঁজার লক্ষণ। নতুন প্রোফাইলের দিকে হাত বাড়ানোর আগে পূর্ণ আকারের প্রোবের দিকে হাত বাড়ান।

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

IPv6 টানেলের উপর দিয়ে চলে তখন ভেতরের MTU কখনোই 1280-এর নিচে নামাবেন না, কারণ প্রতিটি IPv6 লিংককে যা বহন করতে হয় সেই ন্যূনতমটি এটাই। ছোট MTU হলো পথ সম্পর্কে একটি তথ্য, অনুভূতিতে টিউন করার পারফরম্যান্স সেটিং নয়।