বড় আপলোডের সময় VPN কেটে যায়: আগে কিউ পড়ুন

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

প্রতিটি চালানায় একটি করে চলক বদলান এবং এন্ডপয়েন্ট অপরিবর্তিত রাখুন।

পুনরাবৃত্তিযোগ্য লোড তুলনা গড়ে তুলুন

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

কোন ইভেন্টটি আগে দেখা যায় তা লক্ষ করুন। কোনো ত্রুটির আগে রাউন্ড-ট্রিপ সময় বাড়লে তা কিউয়ের ইঙ্গিত দেয়; স্থির লেটেন্সিতে কঠিন টাইমআউট অন্য কিছু, যেমন কী পুনর্নবীকরণ বা অ্যাকাউন্টে কোনো পদক্ষেপের ইঙ্গিত দেয়। দুটি ধরন ভিন্ন পরবর্তী পদক্ষেপে নিয়ে যায়। কিছু বদলানোর আগে পর্যবেক্ষণটি লিখে রাখুন।

আউটপুট টাইমস্ট্যাম্পসহ সংরক্ষণ করুন, যাতে লোডেড ও নিষ্ক্রিয় রানগুলো সারি ধরে তুলনা করা যায়।

গতি নয়, কিউ পড়ুন

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

ping -c 20 -i 0.2 203.0.113.10
mtr -rwc 20 203.0.113.10
tc -s qdisc show dev eth0
ss -ti dst 203.0.113.10
nstat -az | grep -E 'Retrans|Timeout'

লোডেড লেটেন্সির সংখ্যাগুলো নিষ্ক্রিয় অবস্থার সঙ্গে তুলনা করুন। প্যাকেট ক্ষতি ছাড়াই কয়েক ডজন মিলিসেকেন্ড থেকে শতকে লাফানো হলো কিউ; স্থির লেটেন্সিতে ক্ষতি ভিন্ন ত্রুটির দিকে ইশারা করে।

ডিভাইস ও নিয়ন্ত্রণ পথ যাচাই করুন

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

uptime
mpstat -P ALL 1 3
dmesg | grep -i -E 'thermal|throttl'
journalctl -u openvpn-server@server --since '10 min ago' | tail -20

ক্লায়েন্ট টাইমআউট নির্ধারিত কী পুনর্নবীকরণ বা সেশন নীতি-সংক্রান্ত ইভেন্টের সঙ্গেও মিলে যেতে পারে। শুধু অ্যাপ্লিকেশনের ত্রুটি বার্তা নয়, ইভেন্টের ক্রম জানতে ক্লায়েন্টের নিজের লগ পড়ুন।

একটি জিনিস বদলে আবার করুন

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

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

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