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 बजे नभई केही मिनेटमै थाहा होस्।

प्रतिवेदन सहयोग टोलीकहाँ जाँदा खाता पहिचानकर्ता, समय-चिह्नहरू र क्लाइन्टको नाम राख्नुहोस्। पासवर्ड र रिकभरी सामग्री त्यो रेकर्डमा कहिल्यै हुनु हुँदैन।