OpenVPN পরে একটি OTP সেশন বাদ দেয়: পুনরায় প্রমাণীকরণে কী দরকার

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

সমাধান হলো দ্বিতীয় হ্যান্ডশেক কী উপস্থাপন করবে সে সম্পর্কে সিদ্ধান্ত, দীর্ঘতর পুনরায় চেষ্টার টাইমার নয়।

ক্লায়েন্টের দৃষ্টিকোণ থেকে বিনিময়টি অনুসরণ করুন

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

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

auth-gen-token দ্বিতীয় প্রশ্নের উত্তর কে দেবে তা বদলে দেয়

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

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

অ্যাকাউন্টের অবস্থার কী হবে তা স্থির করুন

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

বহু-সার্ভার স্থাপনায় টোকেন স্বাক্ষরের গোপনীয়তা ভাগ করতে হবে, নইলে ক্লায়েন্টকে এমন নোডে পাঠানো হতে পারে যা তার টোকেন যাচাই করতে পারে না।

শুধু লগইন নয়, মেয়াদ শেষ ও পুনঃসংযোগ পরীক্ষা করুন

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

অ্যাকাউন্ট অপসারণ সবার শেষে পরীক্ষা করুন। ওই ঘটনাটি বলে দেয় আপনি যে নীতি লিখেছেন তা কার্যকর হচ্ছে, নাকি কেবল নথিভুক্ত।

নবায়ন বন্ধ করে এটি ঠিক করবেন না

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

দীর্ঘতর পুনরায় চেষ্টার টাইমার ব্যবহৃত কোডকে আবার বৈধ করে না। এটি কেবল সংযোগ বিচ্ছিন্নতা বিলম্বিত করে এবং লগ পড়া কঠিন করে তোলে।