কেন আপনার VPN বিভ্রাটের চেয়ে বেশি সময় নিয়ে পুনরুদ্ধার হয়

ত্রিশ সেকেন্ড আগে Wi-Fi ফিরে এসেছে, তবু VPN এখনো বন্ধ, তাই ক্লায়েন্টটি নষ্ট মনে হয়। প্রায়ই এটি নিজের পুনঃচেষ্টার সময়সূচি অনুসরণ করছে, আর সেই সময়সূচি জানে না যে নেটওয়ার্ক এইমাত্র ফিরেছে। ওই ব্যবধানটাই পুরো গল্প: পুনরুদ্ধারের সময় মানে বিভ্রাটের সঙ্গে ক্লায়েন্ট আগে থেকেই যে অপেক্ষা গ্রহণ করেছে তার যোগফল। প্রতিটি টাইমার কমানো একটি পদক্ষেপ, আর কোন টাইমারটি গুরুত্বপূর্ণ তা বোঝা আরেকটি।

তিনটি শর্ত ঠিক করে টিউনিং সাহায্য করবে কি না: কোন ধাপ ধীর, ব্যর্থতা আদৌ পুনরায় চেষ্টাযোগ্য কি না, এবং নেটওয়ার্ক ফিরে এসেছে তা ক্লায়েন্ট কীভাবে জানবে।

একই রকম দেখানো তিনটি অপেক্ষা

এন্ডপয়েন্ট রেজলিউশন, IKE বা TLS আলোচনা, প্যাকেট পুনঃপ্রেরণ এবং নতুন একটি চেষ্টা শুরু করা আলাদা টাইমারযুক্ত আলাদা ঘটনা। strongSwan পুনঃপ্রেরণের ব্যাকঅফ IKE-এর জন্য নথিভুক্ত করে, আর OpenVPN এর নিজস্ব পুনঃচেষ্টা নিয়ন্ত্রণ আছে ভিন্ন অর্থসহ। একটির সংখ্যা অন্যটিতে কপি করা ধরে নেয় যে প্রক্রিয়াগুলো মেলে, কিন্তু সেগুলো মেলে না। কোন ব্যবধান দেখছেন তা ঠিক করার আগে লগের ক্রম পড়ুন।

লগে এক মিনিটের নীরবতা মানেই জমে যাওয়া প্রক্রিয়া নয়। এটি একটি সূচকীয় ব্যাকঅফ হতে পারে, যা ঠিক তার জন্যই করা হয়েছে যা কনফিগার করা হয়েছিল।

আসলে কোন ধাপ ধীর?

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

কোনো সংখ্যা ছোঁয়ার আগে ব্যর্থতাটি শ্রেণিবদ্ধ করুন।

কখন টাইমার কমানো সাহায্য করে, আর কখন করে না

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

প্রতিটি প্রোফাইলে কপি করা অত্যন্ত কম টাইমআউট হলো পরিমাপ ছাড়া টিউনিংয়ের স্বাভাবিক শেষ অবস্থা।

ক্লায়েন্টকে দোষারোপের আগে প্রস্তুতি যাচাই করুন

কিছু না চেষ্টা করা পর্যন্ত নেটওয়ার্কটি ব্যবহারযোগ্য তা ক্লায়েন্ট প্রায়ই দেখতে পায় না। একটি ক্যাপটিভ পোর্টাল, একটি DHCP নবায়ন বা একটি রুট পরিবর্তন তাকে এমন সময়সূচিতে অপেক্ষা করিয়ে রাখতে পারে যা এসবের আগেই নির্ধারিত হয়েছিল। অপারেটিং সিস্টেমের নেটওয়ার্ক অবস্থার পরিবর্তন এবং ক্লায়েন্টের পরবর্তী চেষ্টা একই ঘড়িতে দেখুন, আর বুঝবেন এটি কার অপেক্ষা। দ্রুত পদ্ধতি হলো নেটওয়ার্ক-প্রস্তুত ঘটনার সময়চিহ্ন এবং তার পরে প্রথম চেষ্টার সময়চিহ্ন লিখে রাখা।

নিশ্চিত করুন যে অপেক্ষার সময় সরাসরি ট্রাফিকও এখনো অবরুদ্ধ আছে, কারণ ট্রাফিক ফাঁস করা দ্রুততর পুনঃসংযোগ কোনো উন্নতি নয়।

কী লিপিবদ্ধ করবেন

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

সেই রেকর্ড পরের সফটওয়্যার আপগ্রেডকে পরীক্ষার বদলে একটি তুলনায় পরিণত করে।