VPN পুনরায় চেষ্টার লুপে অ্যাকাউন্ট লক: আগে ক্লায়েন্ট বন্ধ করুন

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

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

কোন প্রক্রিয়া ব্যর্থতাগুলো পাঠাচ্ছে তা খুঁজুন

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

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

সিদ্ধান্ত নেওয়ার তিনটি শর্ত

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

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

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

আনলক করার আগে প্রেরককে থামান

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

# which unit is presenting the credential?
journalctl -u openvpn-client@home --since '20 min ago' | grep -i 'auth\|error'

# stop it, and keep it stopped across reboots
sudo systemctl stop openvpn-client@home
sudo systemctl disable openvpn-client@home
systemctl is-active openvpn-client@home

কয়েক মিনিট অপেক্ষা করুন এবং ব্যর্থতার সংখ্যা থেমে গেছে কি না নিশ্চিত করুন। ওই বিরতিই প্রমাণ যে আপনি সঠিক উৎস পেয়েছেন। ব্যর্থতা চলতে থাকলে লুপটি অন্য জায়গা থেকে আসছে এবং আনলক করার ধাপটি বৃথা যাবে।

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

কারণটি সরান যাতে তা ফিরে না আসে

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

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

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