VPN কি বারবার বিচ্ছিন্ন হচ্ছে? এই ক্রমে সমাধান করুন

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

প্রথম ধাপ: ব্যবধান ও ত্রুটির লেখা লিখে রাখুন

ভেন্ডরের ড্যাশবোর্ড নয়, ক্লায়েন্টের নিজের লগ দিয়ে শুরু করুন। Linux ক্লায়েন্টে সার্ভিস লগ ও চলমান টানেল অবস্থা মিলে এর বেশিরভাগটাই কভার হয়:

journalctl -u openvpn-client@client --since '3 hours ago' | tail -60
journalctl -u wg-quick@wg0 --since '3 hours ago' | tail -40
wg show
ip -s link show wg0

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

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

দ্বিতীয় ধাপ: প্রোফাইল নয়, একটি চলক বদলান

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

Ethernet পোর্টযুক্ত ল্যাপটপ আপনাকে দ্বিতীয় তুলনা দেয়, যা Wi-Fi-কে ছবি থেকে সম্পূর্ণ সরিয়ে দেয়। টানেল যদি দুই বিকল্পেই টিকে থাকে, তবে মূল অ্যাক্সেস নেটওয়ার্কই মনোযোগ দাবি করে: অ্যাক্সেস পয়েন্ট রোমিং, ট্রান্সলেশন টেবিলের মেয়াদ শেষ হওয়া গ্রাহক রাউটার, বা দীর্ঘস্থায়ী ফ্লো রিসেট করা আপস্ট্রিম লিংক।

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

তৃতীয় ধাপ: ব্যবধানকে স্তরের সঙ্গে মেলান

একটি ভালো সেশনের দৈর্ঘ্যই আপনার কাছে থাকা সবচেয়ে তথ্যবহুল একক সংখ্যা। টাইমার ঠেকানোর আগে এটি এই তালিকার সঙ্গে মিলিয়ে দেখুন:

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

নিষ্ক্রিয়তার ক্ষেত্রে সেটিংস প্রোটোকলভিত্তিক এবং দুই প্রান্তই গুরুত্বপূর্ণ। সার্ভারে OpenVPN-এর keepalive 10 60 প্রতি 10 সেকেন্ডে একটি পিং পাঠায় এবং একটিও না এলে 60 সেকেন্ড পরে লিংক পুনরায় চালু করে; NAT-এর পেছনে WireGuard ক্লায়েন্টরা পিয়ার ব্লকে PersistentKeepalive = 25 ব্যবহার করে। OpenVPN এছাড়াও টাইমার অনুযায়ী ডেটা চ্যানেল পুনঃসমঝোতা করে, reneg-sec, যা 2.x-এ ডিফল্টভাবে 3600 সেকেন্ড।

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

চতুর্থ ধাপ: একটি সমর্থিত বিকল্প তুলনা করুন

অপারেটর যদি UDP ও TCP দুটোই প্রোফাইল প্রকাশ করে, একই ডিভাইস ও নেটওয়ার্ক দিয়ে অন্যটি চালান। কপি করা প্রোফাইলে ট্রান্সপোর্ট সম্পাদনার বদলে প্রকৃত মিলে যাওয়া ফাইলটি ব্যবহার করুন। যেখানে UDP রিসেট হয় সেখানে স্থিতিশীল TCP প্রোফাইল সমস্যাটিকে ওই পথে সংকুচিত করে; এটি প্রমাণ করে না যে TCP সর্বত্রই ভালো ট্রান্সপোর্ট।

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

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

সমাধান যাচাই করুন, আর রোলব্যাক রাখুন

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

wg show wg0 latest-handshakes
curl -m 5 -sS https://ifconfig.me
cp client.ovpn client.ovpn.bak   # before editing timers

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

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