VPN ഗ്രൂപ്പിലേക്ക് ഉപയോക്താവിനെ ചേർക്കുന്നത് സ്വയം പ്രവേശനം നൽകുന്നില്ല
ഗ്രൂപ്പ് അംഗത്വം ഒരു വ്യവസ്ഥയാണ്, അനുമതിയല്ല. ഗേറ്റ്വേ യഥാർത്ഥത്തിൽ എന്താണ് ഒത്തുനോക്കിയതെന്ന് നോക്കുക, സ്വീകരണമോ നിരാകരണമോ ആയ രേഖ വായിക്കുക, രണ്ട് ഫലങ്ങളും പരിശോധിക്കുക.
അക്കൗണ്ട് ശരിയായ ഗ്രൂപ്പിലുണ്ട്, ലോഗിൻ വിജയിച്ചു, എന്നിട്ടും കണക്ഷൻ നിരാകരിക്കപ്പെടുന്നു അല്ലെങ്കിൽ ഉപയോഗപ്രദമായ ഒന്നും എത്തുന്നില്ല. എന്തെങ്കിലും അയയുന്നതുവരെ ഉപയോക്താവിനെ കൂടുതൽ ഗ്രൂപ്പുകളിൽ ചേർക്കുന്നതാണ് സാധാരണ പ്രതികരണം, അങ്ങനെ സംഘടനകൾ ടിക്കറ്റ് ആവശ്യപ്പെട്ടതിനേക്കാൾ ഏറെ നൽകുന്നു. ഗ്രൂപ്പ് അംഗത്വം അനുമതി തീരുമാനത്തിന്റെ ഒരു ഇൻപുട്ട് മാത്രമാണ്, തീരുമാനമല്ല: ഗേറ്റ്വേ സെഷനെക്കുറിച്ച് കുറച്ച് വസ്തുതകൾ ശേഖരിച്ച് ക്രമീകരിച്ച നയവുമായി ഒത്തുനോക്കി, പിന്നീടാണ് എന്തിൽ സ്പർശിക്കാമെന്ന് തീരുമാനിക്കുന്നത്. മറ്റൊരു വ്യവസ്ഥ പരാജയപ്പെട്ടാൽ, ഗ്രൂപ്പ് മാറ്റുന്നത് നിങ്ങളുടെ എക്സ്പോഷർ മാറ്റുന്നു മാത്രം.
ഗ്രൂപ്പ് അംഗത്വം വ്യവസ്ഥയാണ്, അനുമതിയല്ല
RADIUS ൽ ഗ്രൂപ്പ് അനുമതാ ഗുണവിശേഷമായി വരുന്നു, ഗുണവിശേഷങ്ങൾ സെഷനെ വിവരിക്കുന്നു, അനുമതി നൽകുന്നില്ല. സർവർ Access-Accept അല്ലെങ്കിൽ Access-Reject എന്ന് മറുപടി നൽകുന്നു; സ്വീകരിക്കുമ്പോൾ Filter-Id, Class അല്ലെങ്കിൽ RFC 2868 ലെ ടണൽ ഗുണവിശേഷങ്ങൾ ചേർക്കാം, എതിർവശത്തെ നെറ്റ്വർക്ക് ഉപകരണം നിർമ്മാതാവിന്റെ തീരുമാനപ്രകാരം അവ വ്യാഖ്യാനിക്കുന്നു. പ്രോട്ടോക്കോളിൽ ഗ്രൂപ്പിനെ പൂർണ്ണ പ്രവേശനമാക്കുന്ന ഒന്നുമില്ല; ആ മാപ്പിംഗ് ഗേറ്റ്വേയിലോ നെറ്റ്വർക്ക് ആക്സസ് സർവറിലോ നയം ക്രമീകരിച്ചയാൾ എഴുതുന്നു.
അതുകൊണ്ടാണ് ഒരേ ഗ്രൂപ്പ് നാമം രണ്ട് സിസ്റ്റങ്ങളിൽ വ്യത്യസ്തമായി പെരുമാറുന്നത്. Microsoft NPS വ്യവസ്ഥകൾ, പരിധികൾ, ക്രമീകരണങ്ങൾ എന്നിവയിൽ നിന്ന് നെറ്റ്വർക്ക് നയങ്ങൾ നിർമ്മിച്ച് നിശ്ചിത ക്രമത്തിൽ വിലയിരുത്തുന്നു. OpenVPN Access Server ന് സ്വന്തം ഗ്രൂപ്പ്, ആക്സസ് നിയമ മാതൃകയുണ്ട്, കമ്മ്യൂണിറ്റി OpenVPN സർവർ പലപ്പോഴും മുഴുവൻ ചോദ്യവും client-connect സ്ക്രിപ്റ്റിനോ client-config-dir ഫയലിനോ ഏൽപ്പിക്കുന്നു.
തീരുമാനിക്കുന്നത് ഒത്തുപോയ നിയമമാണ്, നിങ്ങൾ പ്രതീക്ഷിച്ച ഗ്രൂപ്പല്ല
മിക്ക എൻജിനുകളും ആദ്യം ഒത്തുപോകുന്ന നയത്തിലോ ഏറ്റവും നിർദ്ദിഷ്ടത്തിലോ നിൽക്കുന്നു. നയം 3 നിരാകരിക്കുകയും നയം 7 അനുവദിക്കുകയും ചെയ്താൽ, കടത്തിവിടുന്ന നിയമത്തിൽ എത്താതെ സെഷൻ പരാജയപ്പെടാം. ക്രമം NPS ലും മിക്ക നെറ്റ്വർക്ക് ആക്സസ് നിയന്ത്രണ ഉൽപ്പന്നങ്ങളിലും യഥാർത്ഥ ക്രമീകരണമാണ്.
ഗ്രൂപ്പിനൊപ്പം പോകുന്ന വ്യവസ്ഥകളാണ് മറ്റേ പകുതി. ഉപകരണാവസ്ഥ, പ്രാമാണീകരണ രീതി, പൂർത്തിയായ MFA, ഉറവിട നെറ്റ്വർക്ക്, സർട്ടിഫിക്കറ്റ് വിഷയം, സമയ വിൻഡോ എന്നിവ ഒരേ നയത്തിലാകാം. ഒന്ന് പൂർത്തിയാകാത്താൽ നയം ഒത്തുപോകില്ല, എൻജിൻ താഴേക്ക് വീഴും, സ്ഥിരസ്ഥിതി നിരാകരണം ബാധകമാകും.
ഡയറക്ടറി വിശദാംശങ്ങളും അതേ മായാജാലം സൃഷ്ടിക്കുന്നു. Windows ഗ്രൂപ്പ് അംഗത്വത്തിൽ ഒത്തുനോക്കുന്ന നയം ടോക്കണിലെ SID വായിക്കുന്നു, അവിടെ സുരക്ഷാ ഗ്രൂപ്പുകൾ മാത്രം, വിതരണ ഗ്രൂപ്പ് ഒരിക്കലും വരില്ല. പ്രാഥമിക ഗ്രൂപ്പ് സ്വന്തം ഫീൽഡിലാണ്, പട്ടികയിലല്ല, അതിനാൽ അതിൽ ഉറപ്പിച്ച നയം നിശ്ശബ്ദമായി പരാജയപ്പെടാം.
ഗ്രൂപ്പിൽ സ്പർശിക്കുന്നതിന് മുൻപ് സ്വീകരണമോ നിരാകരണമോ ആയ രേഖ വായിക്കുക
ആദ്യം ഒരു ചോദ്യം: അഭ്യർത്ഥന അനുമതി ഘട്ടത്തിൽ എത്തിയോ? NPS ൽ ഉത്തരം ഇവന്റ് ലോഗിലുണ്ട്, അവിടെ 6272 നൽകിയ പ്രവേശനം, 6273 നിരാകരണം, 6274 നയം വിലയിരുത്തുന്നതിന് മുൻപ് സർവർ വലിച്ചെറിഞ്ഞ അഭ്യർത്ഥന എന്നിവ രേഖപ്പെടുത്തുന്നു. ആ മൂന്ന് സംഖ്യകൾ പ്രശ്നത്തെ മൂന്ന് വ്യത്യസ്ത അന്വേഷണങ്ങളായി വിഭജിക്കുന്നു, ഒന്ന് മാത്രം ഗ്രൂപ്പുകളെക്കുറിച്ച്.
| What the record shows | What it means | Where to look next |
|---|---|---|
| 6272, access granted | Authentication and authorization both succeeded | Routes, split tunnel, DNS, per-resource rules |
| 6273, access denied | A policy matched and denied, or nothing matched and the default denied | The conditions of the policy that fired, in order |
| 6274, request discarded | The request never reached authorization | Shared secret, NAS client entry, proxy chain, malformed attributes |
ലോഗ് ലഭ്യമല്ലെങ്കിൽ സർവറിനോട് നേരിട്ട് ചോദിച്ച് അത് തിരികെ നൽകുന്നത് വായിക്കുക. Filter-Id ഉം ടണൽ ഗുണവിശേഷങ്ങളും ഇല്ലാത്ത മറുപടി സർവർ സെഷനെ സാധാരണമായി കാണുന്നു, ഗേറ്റ്വേ സ്വന്തം നിയമങ്ങൾ പ്രയോഗിക്കുന്നു എന്നർത്ഥം. നടപ്പാക്കൽ പോയിന്റ് നടപ്പാക്കാത്ത ഗുണവിശേഷങ്ങളുള്ള മറുപടി മറ്റൊരു തകരാറാണ്: അനുമതി കടന്നു, ഉപകരണം ഫലം അവഗണിച്ചു.
radtest alice 'password' 10.0.0.5 0 testing123തിരികെ ലഭിച്ച ഗുണവിശേഷങ്ങളെ ഗേറ്റ്വേ രേഖപ്പെടുത്തുന്നവയുമായി താരതമ്യം ചെയ്യുക, ഗ്രൂപ്പ് നാമം സൂചിപ്പിക്കുന്നതുമായി അല്ല. ആ താരതമ്യം സാധാരണയായി നയപ്രശ്നത്തെ നടപ്പാക്കൽ പ്രശ്നത്തിൽ നിന്ന് വേർതിരിക്കുന്നു.
ഗ്രൂപ്പ് മാറ്റം പിന്നോട്ട് ബാധകമല്ല
അനുമതാ ഗുണവിശേഷങ്ങൾ സെഷൻ പ്രാമാണീകരിക്കുമ്പോൾ ഒരിക്കൽ മാത്രം തിരികെ വരുന്നു. ഗേറ്റ്വേ അവ സെഷനിൽ സൂക്ഷിക്കുകയും ഓരോ പാക്കറ്റിനും ഡയറക്ടറി വീണ്ടും വായിക്കാതിരിക്കുകയും ചെയ്യുന്നു, അതിനാൽ ആരെയെങ്കിലും ഗ്രൂപ്പിൽ നിന്ന് നീക്കിയ ശേഷവും സ്ഥാപിത സെഷൻ പ്രവർത്തിക്കുന്നു.
മാറ്റം പ്രാബല്യത്തിൽ വരാൻ പുതിയ അനുമതാ തീരുമാനം വേണം, പുതിയ കീകൾ മാത്രം പോരാ. സർവർ RFC 5176 ചലനാത്മക അനുമതി പിന്തുണയ്ക്കുന്നിടത്ത് UDP 3799 ലേക്ക് Disconnect-Request അല്ലെങ്കിൽ CoA-Request സെഷൻ വീണ്ടും വിലയിരുത്താൻ നിർബന്ധിക്കുന്നു; അല്ലെങ്കിൽ ക്ലയന്റ് വിച്ഛേദിച്ച് വീണ്ടും ബന്ധിപ്പിക്കാൻ അനുവദിക്കുക. പുനർചർച്ച ടണൽ കീകൾ പുതുക്കി അനുമതാ ഫലം സാധാരണയായി അതേപടി നിർത്തുന്നു.
വ്യവസ്ഥ ശരിയാക്കുക, ഗ്രൂപ്പല്ല
ഏത് നയം പ്രവർത്തിച്ചുവെന്ന് അറിഞ്ഞാൽ അറ്റകുറ്റപ്പണി സാധാരണയായി ചെറുതാണ്: ഉദ്ദേശിച്ച അനുമതിയെ മറയ്ക്കുന്ന നിരാകരണത്തിന്റെ ക്രമം മാറ്റുക, ലക്ഷ്യമിട്ട നയത്തിൽ വിട്ടുപോയ ഉപകരണ അല്ലെങ്കിൽ MFA വ്യവസ്ഥ ചേർക്കുക, അല്ലെങ്കിൽ ഉപയോക്താവിനെ പത്ത് കൂടി വഹിക്കുന്ന ഗ്രൂപ്പിലേക്ക് ഉയർത്തുന്നതിന് പകരം ഒരു വിഭവത്തിന് ഇടുങ്ങിയ നിയമം എഴുതുക.
ചെറിയ ലൂപ്പ് മാറ്റത്തെ സത്യസന്ധമായി നിർത്തുന്നു:
- യഥാർത്ഥ അക്കൗണ്ടുമായി നിരാകരണം പുനർനിർമ്മിച്ച് എന്തെങ്കിലും മാറ്റുന്നതിന് മുൻപ് ഇവന്റ് ID എഴുതുക.
- ഒരു വസ്തു മാത്രം മാറ്റുക, നയക്രമം, ഒരു വ്യവസ്ഥ അല്ലെങ്കിൽ ഒരു ഗ്രൂപ്പ്, ഏതാണെന്ന് രേഖപ്പെടുത്തുക.
- പുതിയ സെഷൻ തുറക്കുക, അനുമതി ലോഗിൽ കാണുന്നുവെന്നും വിഭവം യഥാർത്ഥത്തിൽ തുറക്കുന്നുവെന്നും ഉറപ്പാക്കുക.
- ഇപ്പോഴും നിരാകരിക്കേണ്ട ഉപയോക്താവിനെ പരിശോധിക്കുക, അറ്റകുറ്റപ്പണി നയം അബദ്ധത്തിൽ വിശാലമാക്കാതിരിക്കാൻ.
അനുമതി ശരിയാണെങ്കിലും വിഭവം തുറക്കുന്നില്ലെങ്കിൽ, അനുമതി കടന്ന നിമിഷം പ്രശ്നം റൂട്ടിംഗിലേക്കോ നാമ പരിഹാരത്തിലേക്കോ മാറി. ആ രണ്ട് തകരാറുകൾ വേർതിരിച്ച് നിർത്തുക, അടുത്ത ടിക്കറ്റ് പകുതി ദിവസത്തിന് പകരം മിനിറ്റുകൾ എടുക്കും.