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 વાગ્યે નહીં પણ થોડી મિનિટોમાં ધ્યાનમાં આવે.

રિપોર્ટ સપોર્ટ પાસે જાય ત્યારે ખાતાનો ઓળખકર્તા, સમય-ચિહ્નો અને ક્લાયન્ટનું નામ રાખો. પાસવર્ડ અને રિકવરી સામગ્રી ક્યારેય તે રેકોર્ડમાં ન હોવા જોઈએ.