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 നഷ്ടം എന്നിവയെല്ലാം വിടവുകൾ അവശേഷിപ്പിക്കുന്നു, അതിനാൽ ഒരു ടണൽ ഇപ്പോഴും പ്രവർത്തിക്കുന്നുണ്ടെന്ന് ആരും തീരുമാനിക്കുന്നതിന് മുമ്പ് ലൈവ് സെഷൻ പട്ടിക ചോദിക്കുന്ന ഒരു അനുരഞ്ജന പാത അലേർട്ടിന് വേണം.
ഓഡിറ്റും അറിയിപ്പും വേർതിരിച്ച് നിർത്തുക
ഓഡിറ്റ് സ്ട്രീമിനും അലേർട്ട് സ്ട്രീമിനും വ്യത്യസ്ത ജോലികളാണ്. അക്കൗണ്ട്, ഗേറ്റ്വേ, സെഷൻ ഐഡി, ടൈംസ്റ്റാമ്പുകൾ, അവസാനിപ്പിക്കൽ കാരണം എന്നിവ ഉൾപ്പെടെയുള്ള അസംസ്കൃത രേഖകൾ സൂക്ഷിക്കുക, സാധാരണ ഇമെയിലുകൾ ഗ്രൂപ്പ് ചെയ്യുകയോ അടിച്ചമർത്തുകയോ ചെറിയ ഓൺ-കോൾ പട്ടികയിലേക്ക് അയയ്ക്കുകയോ ചെയ്താലും. തീവ്രതയുടെ പരിധി ഒരു ഡെലിവറി ഫിൽട്ടറാണ്, നിങ്ങൾ പ്രഖ്യാപിക്കാൻ ഉദ്ദേശിച്ച ജീവിതച്ചക്ര സംഭവത്തിന്റെ തിരഞ്ഞെടുപ്പല്ല.
സംരക്ഷിത രേഖ കണ്ടെത്താൻ സ്വീകർത്താവിന് ആവശ്യമായ ഏറ്റവും കുറഞ്ഞ സന്ദർഭം മാത്രം അയയ്ക്കുക. അക്കൗണ്ട് പേരുകൾ, ആന്തരിക വിലാസങ്ങൾ, സെഷൻ വിശദാംശങ്ങൾ എന്നിവ സംവേദനക്ഷമമാണ്, നന്നായി ഫോർവേഡ് ചെയ്യപ്പെടുന്ന ഇമെയിൽ നന്നായി ചോരുന്ന ഇമെയിലാണ്.
പിന്നീട് അത് തുടക്കം മുതൽ അവസാനം വരെ തെളിയിക്കുക. സാധാരണ ലോഗിൻ, ലോഗൗട്ട്, ഒരു വീണ്ടും ബന്ധിപ്പിക്കൽ, ഒരേ സമയം രണ്ട് സെഷനുകൾ, നിർബന്ധിത ഡെലിവറി പരാജയം എന്നിവ പ്രവർത്തിപ്പിക്കുക, ഗേറ്റ്വേയിൽ നിന്ന് ശേഖരണിയിലൂടെ എത്തിയ സന്ദേശം വരെ ഒരു സംഭവം ട്രേസ് ചെയ്യുക. സെഷൻ ഐഡിയില്ലാതെ ഇമെയിൽ എത്തിയാൽ കരാർ അപൂർണ്ണമാണ്. രണ്ട് ഇമെയിലുകൾ ഒരു സെഷനെ വിവരിക്കുന്നുവെങ്കിൽ പരസ്പരബന്ധം തകർന്നിരിക്കുന്നു. മെയിൽ ഡെലിവറി പ്രവർത്തിക്കുന്നു എന്ന് മാത്രം പരിശോധിക്കുമ്പോൾ ഈ രണ്ട് പ്രശ്നങ്ങളും പ്രത്യക്ഷപ്പെടുന്നില്ല.