OpenVPN mssfix: বড় স্থানান্তরে একটি ক্লায়েন্ট কেন থেমে যায়

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

অপশনটি কী পুনরায় লেখে

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

এটি UDP ডেটাগ্রাম ছোট করে না, এবং টানেলের MTU নির্ধারণ করে না। দুটি ভিন্ন সমস্যা একই উপসর্গ তৈরি করে: একটি TCP প্রেরক যা পথের সীমা উপেক্ষা করে, এবং একটি পথ যা যেকোনো আকারের বড় প্যাকেট নিঃশব্দে ফেলে দেয়। mssfix প্রথমটির সমাধান করে এবং দ্বিতীয়টির জন্য কিছুই করে না।

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

পরিধি টানেলের ভিতরের TCP

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

দিকও গুরুত্বপূর্ণ। ক্লায়েন্ট সেটিং সেই ক্লায়েন্ট টানেলে যে ট্রাফিক পাঠায় তাতে প্রভাব ফেলে, অন্যদিকে সার্ভার ক্লায়েন্টের দিকে যে ফ্লো ফরওয়ার্ড করে তা ঢাকে। যদি কেবল অন্তর্মুখী ডাউনলোড থেমে যায়, ক্লায়েন্ট-পাশের মানই পুরো গল্প নয়।

সংখ্যা ও কিওয়ার্ড বহনযোগ্য নয়

OpenVPN 2.6-এর কমিউনিটি সংস্করণ মানের পরে একটি ঐচ্ছিক কিওয়ার্ড গ্রহণ করে। mtu সহ, সংখ্যাটি IP ও UDP হেডারসহ বাইরের প্যাকেট আকার বর্ণনা করে; এটি ছাড়া আর্গুমেন্ট ভিন্ন হিসাবরক্ষণ প্রথা অনুসরণ করে। তাই সংস্করণের মধ্যে কপি করা একটি লাইন একই প্যাকেট বাজেট বর্ণনা করে না। অন্য রিলিজের টিউটোরিয়ালের বদলে আপনি সত্যিই যে বিল্ড চালান তার সঙ্গে আসা ম্যানুয়াল পৃষ্ঠাটি দেখুন।

সিনট্যাক্সটি এমন দেখায়:

mssfix 1400 mtu

1400-কে আপনার পথের জন্য সুপারিশ নয়, বরং প্লেসহোল্ডার হিসেবে ধরুন। মানটি মাপা পথ ও প্রকৃতপক্ষে ব্যবহৃত এনক্যাপসুলেশন থেকে বের করুন, এবং মনে রাখুন পুরোনো সংস্করণ বা অন্য বাস্তবায়নের ক্লায়েন্টরা কিওয়ার্ডটি প্রত্যাখ্যান বা ভিন্নভাবে ব্যাখ্যা করতে পারে।

প্রথমে একক ক্লায়েন্টে নিশ্চিত করুন

কিছু বদলানোর আগে ব্যর্থ মেশিন থেকে পথটি মাপুন। যে পেলোড পথটি খণ্ডন ছাড়াই বহন করতে পারে সেটিই আপনার খোঁজা সংখ্যা:

ping -M do -s 1472 10.8.0.1
ping -M do -s 1400 10.8.0.1

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

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