vpnc কেন 24 মিনিটে সংযোগ বিচ্ছিন্ন করে এবং কী পরিবর্তন করবেন

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

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

কোন টাইমার বিচ্ছিন্নতার মালিক

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

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

প্রথম ঘটনা: ক্লায়েন্ট নিষ্ক্রিয় সেশন ছেড়ে দেয়

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

DPD idle timeout (our side) 0
NAT Traversal Mode cisco-udp

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

দ্বিতীয় ঘটনা: রিকি প্রত্যাখ্যাত হয়

বিরতি যদি DPD পরিবর্তন সত্ত্বেও টিকে থাকে, তবে 1 নম্বর ফেজের রিকি প্রার্থী হয়। পুরোনো vpnc বিল্ডগুলো বর্তমানগুলোর চেয়ে কম সতর্কভাবে রিকি সামলাত, আর স্বাভাবিক মতভেদ হলো Diffie-Hellman গ্রুপ। হেড-এন্ড ইতিমধ্যে যে গ্রুপ গ্রহণ করে তা জোর করা এক লাইন এবং এক পুনঃসংযোগ খরচ করে, যা এটিকে নীতি পরিবর্তনের বদলে সস্তা পরীক্ষায় পরিণত করে।

IKE DH Group dh5

বৈধ গ্রুপ নামগুলো হলো dh1, dh2 এবং dh5। কনসেনট্রেটর যে গ্রুপ প্রত্যাখ্যান করে তা তাৎক্ষণিক ব্যর্থতা দেয়, এবং সেটিও তথ্য: এটি বলে যে হেড-এন্ড খুঁতখুঁতে এবং মূল গ্রুপটি সম্ভবত সঠিক ছিল।

তৃতীয় ঘটনা: অনুবাদ এনক্যাপসুলেশন পুনরায় লেখে

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

ফ্রন্টএন্ডগুলো এখানে নিজেদের বিভ্রান্তি যোগ করে। প্লাগইন প্যাকেজ ইনস্টল না হলে NetworkManager vpnc সংযোগের ধরন দেয় না, আর অনুপস্থিত প্লাগইন ত্রুটি হিসেবে নয় বরং ধূসর করা Add বোতাম হিসেবে দেখায়। KDE-র ফ্রন্টএন্ড একই মান নিজের প্রোফাইলে রাখে, তাই ডেমনটি আপনার সম্পাদিত জিনিস পড়ছে কি না নিশ্চিত করুন।

যে প্রোফাইল কমান্ড লাইন থেকে ভালোভাবে সংযোগ করে কিন্তু ডেস্কটপ থেকে করে না, সেটি ফ্রন্টএন্ডের সমস্যা, টাইমারের সমস্যা নয়।

তৃতীয় পরিবর্তনের আগে যে বিনিময় ব্যর্থ হয় তা যাচাই করুন

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

vpnc --debug 3 office

টানেল টিকে থাকলে কিন্তু ট্রাফিক থেমে গেলে দ্বিতীয় নেটওয়ার্ক ডেমনও খুঁজুন। রাউটিং টেবিল লেখা দুটি ম্যানেজার ডেস্কটপ থেকে একই উপসর্গ এবং সম্পূর্ণ ভিন্ন লগ তৈরি করে।