OpenVPN অসমভাবে MTU ব্যবহারের সতর্কবার্তা দেয়: বার্তাটি কী তুলনা করে

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

উত্তর তিনটি শর্তে নির্ধারিত হয়: পিয়াররা কী তুলনা করে, মানটি পুরোনো কি না, এবং সতর্কবার্তার বাইরে কোন উপসর্গ আছে।

সতর্কবার্তা প্যাকেট নয়, অপশান তুলনা করে

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

সম্পূর্ণ সতর্কবার্তাটি এর লোকাল ও রিমোট মানসহ রেখে দিন। জোড়াটিই প্রমাণ; আপনার মনে থাকা একক সংখ্যাটি নয়।

link-mtu কেন পুরোনো হয়ে গেছে

OpenVPN 2.6 link-mtu অপশানটি পুরোনো ঘোষণা করেছে, কারণ পরিবর্তনশীল হেডার ও সমঝোতা করা সাইফার স্থির লিংক মানকে অবিশ্বস্ত করে তোলে। অপশানটি এমন প্যাকেট বিন্যাস ধরে নিয়েছিল যা প্রোটোকল আর নিশ্চিত করে না, তাই আক্ষরিক link-mtu বহন করা পুরোনো প্রোফাইল এমন একটি অভিপ্রায় বর্ণনা করে যা বর্তমান কোড মানতে পারে না। সেই সংখ্যাটি নতুন প্রোফাইলে কপি করলে একটি অপ্রচলিত ধারণা ছড়ায়। এটি সুপারিশ নয়, পুরোনো প্রোফাইলের ইতিহাসের অংশ হিসেবে পড়ুন।

সামঞ্জস্য যাচাইয়ের একটি ঐচ্ছিক OCC মানও আছে যা tun-mtu-এর সঙ্গে যুক্ত, এটি কী তুলনা হয় তা বদলায় কিন্তু নেটওয়ার্ক কী বহন করে তা বদলায় না। এটি সেট করলে বড় প্যাকেট জায়গা পায় না।

পথ পরীক্ষা করার আগে প্রোফাইল ঠিক করুন

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

ভাগ করা সার্ভারে কোনো বৈশ্বিক মান সরানোর আগে ক্লায়েন্ট তালিকা যাচাই করা দরকার, কারণ যে মান একটি সাইটের জন্য উপযুক্ত তা অন্য সাইট ভেঙে দিতে পারে।

তারপর যে উপসর্গটি সত্যিই আছে তা পরীক্ষা করুন

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

mssfix টানেলের ভিতরের TCP সেশনগুলোর জন্য ঘোষিত MSS সীমাবদ্ধ করে, যা TCP-তে সাহায্য করে এবং ভিতরের UDP কাজে কিছুই করে না। ফ্র্যাগমেন্টেশন ও অফলোড সেটিংসের নিজেদের সামঞ্জস্যের শর্ত আছে। লগের একটি লাইন শান্ত করতে একসঙ্গে কয়েকটি বদলানোর বদলে প্রমাণিত সমস্যার জন্য একটি পদ্ধতি বেছে নিন।

কার্যকর মানগুলো ফলাফলের সঙ্গে রাখুন

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

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