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 बजे के बजाय कुछ मिनटों में पकड़ में आए।

जब रिपोर्ट सहायता टीम के पास जाए, तो खाता पहचानकर्ता, समय-चिह्न और क्लाइंट का नाम रखें। पासवर्ड और रिकवरी सामग्री उस रिकॉर्ड में कभी नहीं होनी चाहिए।