VPN લોગિન ચેતવણીઓ: કઈ ઘટનાએ તેમને ખરેખર ટ્રિગર કરવી જોઈએ?
પ્રમાણીકરણની સફળતા, સ્થાપિત ટનલ અને RADIUS accounting Start એ ત્રણ અલગ દાવા છે. તમારો પ્રાપ્તકર્તા જેના પર કાર્ય કરી શકે તે દાવો પસંદ કરો, પછી તેમને સહસંબંધિત કરો.
પ્રમાણીકરણની સફળતા, સ્થાપિત ટનલ અને RADIUS accounting Start એ ત્રણ અલગ દાવા છે, અને લોગિન ઈમેલ ત્યારે જ અર્થ ધરાવે છે જ્યારે તમે તેમાંથી એક પસંદ કરો. મોટાભાગની VPN ચેતવણી ડિઝાઇન ત્રણેયને મિશ્ર કરે છે અને એવું ઇનબોક્સ બનાવે છે જેના પર કોઈ ભરોસો કરતું નથી. નિર્ણય એના પર આવે છે કે ચેતવણી કોણ વાંચે છે અને આગલી પાંચ મિનિટમાં તે શું કરી શકે છે. આ ખોટું કરો તો ચેતવણી એવો ઘોંઘાટ બની જાય છે જે તમને જરૂરી એકમાત્ર ઘટનાને છુપાવે છે.
ત્રણ પ્રશ્નો ટ્રિગર નક્કી કરે છે
પૂછો કે તે કોને મળશે, તેઓ શું કરશે, અને ક્રિયા કેટલી ઝડપથી થવી જોઈએ. ઓળખપત્રોના દુરુપયોગ પર નજર રાખતી સુરક્ષા ટીમને એક ખાતામાંથી મિનિટોમાં નિષ્ફળ-પછી-સફળ પેટર્ન જોઈએ છે. ક્ષમતા પર નજર રાખતી ઓપરેશન્સ ટીમને સત્રનો સમયગાળો અને ડિસ્કનેક્ટના કારણો જોઈએ છે, લોગિન નહીં. હેલ્પડેસ્કને સત્રની ઓળખ જોઈએ છે જેથી તે ટિકિટ સાથે મેળ કરી શકે.
તે જવાબો અલગ ઘટનાઓ તરફ ઇશારો કરે છે, અને કોઈ એક નિયમ ત્રણેયને સંતુષ્ટ કરતો નથી. જો પ્રાપ્તકર્તાની ક્રિયા «વપરાશકર્તાને ફોન કરો» હોય, તો પ્રમાણીકરણ પૂરતું છે. જો ક્રિયા «લાઇસન્સ મુક્ત કરો» અથવા «ટનલે ટ્રાફિક વહન કર્યો છે તે ચકાસો» હોય, તો ફક્ત સ્થાપના અથવા accounting Start જ કામ કરશે. જો ક્રિયા «સમયનું બિલ કરો» હોય, તો તમને લોગિનને બદલે Stop રેકોર્ડની જરૂર છે.
કંઈપણ ગોઠવતા પહેલાં જવાબ એક વાક્યમાં લખો. «આ ઈમેલ ઓન-કોલ એન્જિનિયરને જણાવે છે કે ખાતું X એ સમય Z પર નેટવર્ક Y થી ટનલ ખોલી છે, જેથી તે ચકાસી શકે કે જાળવણી વિન્ડોનો ઉપયોગ થયો હતો કે નહીં.» જો તમે દરેક જગ્યા ભરી શકતા નથી, તો ટ્રિગર હજી પસંદ થયો નથી.
ઘટનાને તમે કરી રહ્યા છો તે દાવા સાથે મેળવો
| Record | What it proves | What it leaves open |
|---|---|---|
| Rejected credentials | The attempt failed at the credential step | Whether it was a stale client or a real person |
| Access-Accept | Credentials passed for this attempt | Anything about tunnel state or policy |
| Policy match record | A rule matched the request | Whether later steps completed |
| Tunnel established | The gateway accepted a session | Whether traffic flowed or the user got an address |
| Accounting Start | User service began at the accounting layer | Whether the application behind it worked |
| Accounting Stop | That session was closed, with a reason field | Whether the reason is meaningful on your release |
કોષ્ટક એક નિર્ભરતા છુપાવે છે: દરેક પંક્તિ ત્યારે જ વિશ્વસનીય છે જ્યારે ગેટવે તેને વિશ્વસનીય રીતે બહાર કાઢે અને તમારો સંગ્રાહક તમને જરૂરી ફીલ્ડ રાખે. તમે ચલાવો છો તે ચોક્કસ આવૃત્તિ માટે ઘટનાની વ્યાખ્યા વાંચો, કારણ કે «સત્ર સ્થાપિત» નામ આવૃત્તિઓ વચ્ચે બદલાય છે અને અર્થ નામ કરતાં વધુ વાર બદલાય છે. જ્યારે વ્યાખ્યા અસ્પષ્ટ હોય, ત્યારે લેબલ પરથી અનુમાન કરવાને બદલે સત્ર કેપ્ચર માંગો.
Access-Accept ને તેના પછીની દરેક વસ્તુની પૂર્ણતા તરીકે ગણવો એ સૌથી સામાન્ય ભૂલ છે. તે ઓળખપત્રો વિશેનો ચુકાદો છે, સત્ર નહીં. વિરુદ્ધ ભૂલ એ છે કે નીતિ મેળને અધિકૃતતાના પુરાવા તરીકે વાંચવો, જ્યારે નિયમ મેળ ખાઈ શકે અને પછીનું પગલું તોપણ નિષ્ફળ જઈ શકે.
એક સત્ર, એક સૂચના
એક ખાતું, ઘણા ઉપકરણો, પુનઃપ્રેષણ અને પુનઃકનેક્શન: દરેક ઘટના માટે એક ઈમેલ બંને દિશામાં ખોટો હશે, એક સત્રને નકલ કરશે જ્યારે બીજાને વિભાજિત કરશે. સૂચનાની કી ગેટવે ઉપરાંત સત્ર ઓળખકર્તા પર રાખો, અને ખાતાના નામને કીને બદલે લક્ષણ તરીકે ગણો. લેપટોપ અને ફોન ધરાવતો વપરાશકર્તા એક સાથે બે ટનલ રાખી શકે છે, અને બંને પોતાની લાઇનને પાત્ર છે.
પુનઃપ્રેષિત હિસાબી રેકોર્ડ સામાન્ય છે, તેથી સંદેશ રેન્ડર કરતા પહેલાં સત્ર આઈડી અને ટાઇમસ્ટેમ્પ પર ડુપ્લિકેટ દૂર કરો. એક જ ઉપકરણના અનુક્રમિક સત્રો અલગ રહેવા જોઈએ, અને જાળવણી વિન્ડો દરમિયાન પુનઃકનેક્શન અગાઉના સત્રમાં ભળી જવાને બદલે દૃશ્યમાન રહેવું જોઈએ. જો તમારો સંગ્રાહક સ્વીકાર સમયે ટાઇમસ્ટેમ્પ ફરીથી લખે છે, તો સંગ્રહિત ફીલ્ડ પર નહીં, મૂળ રેકોર્ડના ફીલ્ડ પર ડુપ્લિકેટ દૂર કરો.
ખૂટતો Stop રેકોર્ડ અનિશ્ચિતતા છે, કાયમી સત્ર નહીં. ગેટવે રીબૂટ, સંગ્રાહક ખામી અને UDP નુકસાન બધા ખાલી જગ્યા છોડે છે, તેથી ચેતવણીને સમાધાનનો માર્ગ જોઈએ છે જે કોઈ ટનલ હજી ચાલુ છે તેવું તારણ કાઢે તે પહેલાં જીવંત સત્ર કોષ્ટકને પૂછે.
ઓડિટ અને સૂચના અલગ રાખો
ઓડિટ પ્રવાહ અને ચેતવણી પ્રવાહના કામ અલગ છે. કાચા રેકોર્ડ રાખો, જેમાં ખાતું, ગેટવે, સત્ર આઈડી, ટાઇમસ્ટેમ્પ અને સમાપ્તિનું કારણ સામેલ છે, ત્યારે પણ જ્યારે નિયમિત ઈમેલ જૂથબદ્ધ, દબાવેલા કે નાની ઓન-કોલ સૂચિ પર મોકલવામાં આવે. ગંભીરતાની થ્રેશોલ્ડ એ વિતરણ ફિલ્ટર છે, તમે જાહેર કરવા માંગતા હતા તે જીવનચક્ર ઘટનાની પસંદગી નહીં.
સુરક્ષિત રેકોર્ડ શોધવા માટે પ્રાપ્તકર્તાને જરૂરી ન્યૂનતમ સંદર્ભ મોકલો. ખાતાના નામ, આંતરિક સરનામાં અને સત્રની વિગતો સંવેદનશીલ છે, અને જે ઈમેલ સારી રીતે ફોરવર્ડ થાય છે તે સારી રીતે લીક પણ થાય છે.
પછી તેને શરૂઆતથી અંત સુધી સાબિત કરો. સામાન્ય લોગિન અને લોગઆઉટ, એક પુનઃકનેક્શન, બે એકસાથે સત્રો અને એક ફરજિયાત વિતરણ નિષ્ફળતા ચલાવો, અને ગેટવેથી સંગ્રાહક થઈને પહોંચાડાયેલા સંદેશ સુધી એક ઘટના ટ્રેસ કરો. જો ઈમેલ સત્ર આઈડી વિના આવે, તો કરાર અધૂરો છે. જો બે ઈમેલ એક સત્રનું વર્ણન કરે, તો સહસંબંધ તૂટેલો છે. જ્યારે તમે ફક્ત એ જ ચકાસો છો કે મેલ વિતરણ કામ કરે છે, ત્યારે બંનેમાંથી કોઈ સમસ્યા દેખાતી નથી.