আমার VPN কেন এত ধীর? এই চারটি অংশ পরীক্ষা করুন

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

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

মাপার আগে ঠিক করুন ধীর মানে কী

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

সেই রেকর্ড ছাড়া পরের প্রতিটি তুলনা হয়ে দাঁড়ায় ধারণা নিয়ে তর্ক।

আগে অ্যাক্সেস নেটওয়ার্ক দেখুন

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

ping -c 20 192.168.50.1
ping -c 20 198.51.100.7
curl -o /dev/null -w "%{time_starttransfer} %{speed_download}\n" https://speed.example.net/10mb.bin

যদি বেসলাইন আগেই খারাপ হয়, তবে কাজটি Wi-Fi, রাউটারের চাপ বা অ্যাক্সেস পরিষেবার। তারযুক্ত পরীক্ষা বা অ্যাক্সেস পয়েন্টের কাছে স্থির অবস্থান দুর্বল রেডিও লিঙ্ককে ভিড়ের আপলিঙ্ক থেকে আলাদা করে। টানেল যা-ই করুক, অ্যাক্সেস লাইন যে ক্যাপাসিটি দিচ্ছে না তা যোগ হবে না।

এক্সিট বদলান, তারপর ট্রান্সপোর্ট

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

যেখানে পরিষেবা দুটি প্রোফাইলই দেয়, সেখানে UDP-তে OpenVPN আর TCP-তে OpenVPN তুলনা করুন। ইন্টারঅ্যাকটিভ কাজের স্বাভাবিক শুরু UDP, আর TCP সাহায্য করতে পারে এমন অ্যাক্সেস নেটওয়ার্কে যা UDP ট্রাফিক একেবারেই পার করে না। TCP টানেল স্ট্রিমের ভিতরে পুনঃপ্রেরণ করে ক্ষতি পূরণ করে, তাই প্যাকেট ফেলানো লিঙ্কে এটি ধীর মনে হতে পারে, এবং OpenVPN পারফরম্যান্স সমস্যা সমাধানের নোট অন্য কিছু টিউন করার আগেই একই বিনিময়টি ব্যাখ্যা করে। প্রোফাইলে "udp" শব্দটি "tcp"-তে বদলালে এমন লিসেনার তৈরি হয় না যা সার্ভার কখনও খোলেনি।

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

ডিভাইস ও উপসর্গ একসঙ্গে পড়ুন

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

ping -M do -s 1400 -c 3 198.51.100.7
ip link show dev tun0 | grep -o "mtu [0-9]*"

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