એક વપરાશકર્તા VPN માં સાઇન ઇન કરી શકતો નથી: ક્રમબદ્ધ નિદાન

જ્યારે એક વ્યક્તિ કનેક્ટ થઈ શકતી નથી જ્યારે બાકીની ટીમ કામ ચાલુ રાખે છે, ત્યારે ઉપયોગી પ્રશ્ન એ નથી કે શું તૂટ્યું છે, પણ એ છે કે કયું સ્તર સંમત ન થયું. સાઇન ઇન એક શૃંખલા છે: ક્લાયન્ટ શરૂ થાય છે, ગેટવે જવાબ આપે છે, ઓળખ રજૂ થાય છે, બીજું પરિબળ સંતોષાય છે, નીતિનું મૂલ્યાંકન થાય છે, અને ત્યાર પછી જ ટ્રાફિક વહે છે. તે શૃંખલામાં ગમે ત્યાં તૂટ પડવું તમારા સુધી વપરાશકર્તાના એ જ વાક્ય તરીકે પહોંચે છે, તેથી પહેલું કામ એ છે કે ખરેખર નિષ્ફળ ગયેલી કડી શોધવી.

અહેવાલને નિદાન નહીં, શરૂઆતના બિંદુ તરીકે ગણો. નીચેની તપાસો સૌથી સસ્તાથી શરૂ થાય છે, અને દરેક એ રીતે લખાયેલી છે કે નિષ્ફળ જાય ત્યારે તપાસ સમાપ્ત થાય.

તબક્કો અને સમયછાપ નક્કી કરો

કોઈપણ રૂપરેખાંકનને સ્પર્શ કરતાં પહેલાં ચાર વસ્તુઓ લખો: ક્લાયન્ટ અને તેની આવૃત્તિ, સ્ક્રીન પરનું ચોક્કસ શબ્દો, પ્રયાસની મિનિટ, અને વ્યક્તિ જે નેટવર્ક પર હતી તે. શબ્દો સાચી માહિતી ધરાવે છે, કારણ કે નકારાયેલા ઓળખપત્રો, જવાબ ન આપતું ગેટવે અને પૂર્ણ થયેલું સાઇન ઇન જે હજી આંતરિક પૃષ્ઠ ખોલી શકતું નથી એ ત્રણ અલગ માલિકો સાથેની ત્રણ અલગ સમસ્યાઓ છે. નોંધો કે ક્લાયન્ટે સ્થાનિક લોગ લાઇન બનાવી છે કે નહીં, કારણ કે જે ક્લાયન્ટે ક્યારેય પેકેટ મોકલ્યું નથી તે સર્વર-બાજુની શોધમાં કંઈ ઉમેરી શકતું નથી. સમયછાપ નોંધાયા પછી, દરેક પછીની પૂછપરછ શિકારને બદલે શોધ બની જાય છે.

આ બિંદુએ પાસવર્ડનો અંદાજ લગાવવાનું બંધ કરો. જ્યાં ખાતાની ફરી પ્રયાસની મર્યાદા છે, ત્યાં ઝડપી પ્રયાસોનો સમૂહ તેને લૉક કરી શકે છે અને સાચી ખામી ઉપર બીજી, કૃત્રિમ ખામી ઉમેરી શકે છે. પહેલેથી કેટલા પ્રયાસો થયા છે તે નોંધો, જેથી લૉકઆઉટને પછી નવું લક્ષણ ન ગણવામાં આવે. લૉક થયેલું ખાતું ખોટા પાસવર્ડને નકારાયેલી નીતિથી અલગ પાડવાની તમારી ક્ષમતા પણ દૂર કરે છે, કારણ કે બંને ઇનકાર તરીકે આવે છે.

તે એક જ પ્રયાસ માટે ઓળખ-ઘટના વાંચો

વ્યવસ્થાપકને તમે નોંધેલી મિનિટ સાથે મેળ ખાતું પ્રમાણીકરણ રેકોર્ડ કાઢવા કહો. Windows NPS જમાવટમાં, Microsoft ની NPS સમસ્યાનિવારણ માર્ગદર્શિકા નકાર ઘટના 6273 ને તેની સાથે આવતા કારણ કોડ સાથે દસ્તાવેજ કરે છે, જે સામાન્ય રીતે અજાણ્યા વપરાશકર્તા, ખરાબ ઓળખપત્રો, નીતિની અસંગતિ અને અસંબંધિત કારણસર પડી ગયેલા કૉલને અલગ પાડે છે.

ખાલી પરિણામ પણ માહિતી છે. જો ઓળખ સેવા સુધી કંઈ પહોંચ્યું નથી, તો પ્રયાસ પહેલાં મૃત્યુ પામ્યો: પ્રોફાઇલમાં જૂનું ગેટવે સરનામું, એવો શ્રોતા જે સુધી ક્લાયન્ટ પહોંચી શકતું નથી, અથવા એવો હોસ્ટ જે પ્રોફાઇલ જીવતું હતું ત્યારે નિવૃત્ત કરાયો. જો રેકોર્ડ અસ્તિત્વમાં છે અને સફળતા જણાવે છે, તો ઓળખપત્રો સમસ્યા નથી અને ચર્ચા અધિકૃતિકરણ તરફ અથવા ગેટવે પાછળના માર્ગ નિર્ધારણ તરફ જાય છે. આ બે પરિણામો વિરુદ્ધ દિશામાં ઈશારો કરે છે, તેથી કોઈ ક્લાયન્ટ ફરી સ્થાપિત કરે તે પહેલાં લોગ શોધ થવી જોઈએ.

કારણ કોડ ટિકિટમાં રાખો. એ એક ક્ષેત્ર આગલી ઘટનાને પુનરાવર્તિત તપાસને બદલે પાંચ મિનિટની શોધમાં ફેરવે છે. તેને ક્લાયન્ટ આવૃત્તિ સાથે જોડો, કારણ કે એક બિલ્ડ પર દેખાતો કોડ દરેક બિલ્ડ પર દેખાતા કોડ કરતાં અલગ વાતચીત છે.

નીતિની અંદર, એક વખતે એક શરત બદલો

લોભ એ છે કે ક્લાયન્ટ ફરી સ્થાપિત કરો, પાસવર્ડ રીસેટ કરો અને લેપટોપને એક જ ફેરમાં બીજા નેટવર્ક પર ખસેડો. તે ક્યારેક લક્ષણ સુધારે છે અને હંમેશા પુરાવા નષ્ટ કરે છે. તેના બદલે એક માન્ય અદલાબદલી પસંદ કરો: એ જ વ્યક્તિ બીજા નોંધાયેલા ઉપકરણ પર, અથવા એ જ ઉપકરણ પર મંજૂર પરીક્ષણ ઓળખ. દરેક અદલાબદલી બરાબર એક પ્રશ્નનો જવાબ આપે છે, તેથી સફળતા ખામીને તમે બદલેલી બાજુ સુધી સંકુચિત કરે છે, આખા VPN ને દોષ નહીં.

આ સરખામણી કરવા માટે સહકર્મીના ઓળખપત્રો ઉધાર ન લો. સમર્થિત પ્રક્રિયા દ્વારા પરીક્ષણ ઓળખ વાપરો, અને ઝડપી થશે તેમ કહીને કદી ઉપકરણ કી કૉપી ન કરો કે નોંધણી છોડી ન દો. જ્યાં નીતિ અદલાબદલી સંપૂર્ણપણે પ્રતિબંધિત કરે છે, ત્યાં તે મર્યાદા પરીક્ષણ હેઠળની સિસ્ટમનો ભાગ છે અને તે રેકોર્ડમાં રહેવી જોઈએ, કોઈ ટાળવાના ઉપાયમાં નહીં.

મૂળ માર્ગ પર સમારકામની પુષ્ટિ કરો

જ્યારે તૂટેલી કડી ઓળખાય, ત્યારે ફક્ત તે કડી સુધારો અને મૂળ પ્રયાસનું પુનરાવર્તન કરો: એ જ વ્યક્તિ, એ જ ઉપકરણ, એ જ નેટવર્ક, એ જ એપ્લિકેશન. વ્યવસ્થાપક VLAN થી કનેક્ટ થતું પરીક્ષણ ખાતું સાબિત કરે છે કે ગેટવે જીવંત છે, અને તે વપરાશકર્તાની મંગળવારની સવાર વિશે કંઈ સાબિત કરતું નથી. વપરાશકર્તાને સરળ કાર્યને બદલે એ જ કાર્ય કરવા કહો જે નિષ્ફળ ગયું, કારણ કે સફળ ping નકારાયેલ ફાઇલ શેરિંગ વિશે થોડું કહે છે.

શું બાકાત રહ્યું અને શું બદલાયું તેની સાથે ટિકિટ બંધ કરો. એ નોંધ એકવારની બચાવ અને આગલા ડ્યુટી ઇજનેર ફરી વાપરી શકે તેવી વસ્તુ વચ્ચેનો તફાવત છે.