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 वाजता नव्हे तर काही मिनिटांत लक्षात येईल।

अहवाल सहाय्याकडे गेल्यावर खाते ओळखकर्ता, वेळ-चिन्हे आणि क्लायंटचे नाव ठेवा। पासवर्ड आणि पुनर्प्राप्ती साहित्य त्या नोंदीत कधीही नसावेत।