সন্দেহজনক VPN MTU সমস্যা মান অনুমান না করে পরীক্ষা করা

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

সংখ্যা বদলানোর আগে পথ নির্ধারণ করুন

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

আপনি চালানোর অনুমতি পান এমন সবচেয়ে সংকীর্ণ পরীক্ষা দিয়ে শুরু করুন। সার্ভার পাশের পরিবর্তন ওই শেষ বিন্দুর প্রতিটি ব্যবহারকারীর কাছে পৌঁছায়, তাই এটি তদন্তের শেষে যায়, শুরুতে নয়।

আপনি যে আকার নিয়ন্ত্রণ করেন তা দিয়ে পরীক্ষা করুন

Linux-এ পরীক্ষাটি ping -M do -s 1400 host এর মতো দেখায়, আর Windows-এ ping -f -l 1400 host এর মতো। দুই ক্ষেত্রেই আপনি পেলোড নির্ধারণ করছেন, প্যাকেটের আকার নয়, কারণ IP এবং ICMP হেডার উপরে যোগ হয়।

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

ব্যর্থ পরীক্ষা MTU সীমার প্রমাণ নয়

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

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

ক্লায়েন্ট ইতিমধ্যে সমর্থন করে এমন একটি মাত্র প্যারামিটার সমন্বয় করুন

ক্লায়েন্ট এই প্রোটোকলের জন্য যে সেটিং নথিভুক্ত করে তা বদলান এবং শেষ বিন্দু ও গন্তব্য অক্ষত রাখুন, নইলে আপনি একসঙ্গে দুটি জিনিস বদলেছেন। TCP MSS ক্ল্যাম্প প্রতিটি UDP ভার ঢাকে না, তাই কাজ শুরু করা ব্রাউজার টানেল প্রোটোকলকে ঠিক তেমনই ভাঙা রেখে যেতে পারে। IPv4 এবং IPv6 এখানে আলাদা পথ, কারণ কোনো রাউটিং কিছু করার আগেই হেডার আলাদা।

দুটোই প্রকাশ করলে দুই পরিবারই পরীক্ষা করুন, কারণ একটির ফলাফল অন্যটি সম্পর্কে কিছু বলে না। আজ রাতে এই পথে যে মান কাজ করেছে তা একটি উপাত্ত, পুরো VPN-এর জন্য MTU নয়। একটি সফল স্থানান্তরের জোরে সেটিকে বৈশ্বিক সেটিংয়ে উন্নীত করবেন না। মানটি যে পথ থেকে এসেছে তার পাশে লিখে রাখুন।

ফিরিয়ে নেওয়া, যাচাই করা এবং লেখা

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

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