NPS ഗ്രൂപ്പ് നയം VPN ഉറവിട നിർവ്വഹണമല്ല
ഒരു ഗ്രൂപ്പിനെ ബന്ധിപ്പിക്കാൻ അനുവദിക്കുന്നത് അത് എത്തുന്നതിനെ പരിമിതപ്പെടുത്തുന്നതല്ല. പൊരുത്തപ്പെടുന്ന നയം, തിരികെ നൽകിയ അംഗീകാരം, ഗേറ്റ്വേയുടെ സ്വന്തം നിർവ്വഹണം എന്നിവ പരിശോധിക്കുക.
രണ്ട് ഗ്രൂപ്പുകൾ, രണ്ട് ആക്സസ് പ്രൊഫൈലുകൾ, ഒരു VPN ഗേറ്റ്വേ, ഒടുവിൽ രണ്ട് ഗ്രൂപ്പുകളും ഒരേ സെർവറുകളിൽ എത്തുന്നു. സാധാരണ കാരണം തകർന്ന നയമല്ല, മറിച്ച് ഡിസൈനിന്റെ കാണാതായ രണ്ടാം പകുതിയാണ്: ആര് സെഷൻ സ്ഥാപിക്കാം എന്ന് NPS തീരുമാനിക്കുന്നു, ആ സെഷൻ എന്തിൽ എത്താം എന്ന് മറ്റൊന്ന് തീരുമാനിക്കണം. ആദ്യ പകുതി മാത്രം ഉള്ളപ്പോൾ, പ്രാമാണീകരണം നടത്തുന്ന എല്ലാവർക്കും അംഗീകാരം വിജയിക്കുന്നു. നയം അതിന്റെ ജോലി ചെയ്യുന്നു, ഡിസൈൻ ഇപ്പോഴും അപൂർണ്ണമാണ്.
ഗ്രൂപ്പിനോട് പൊരുത്തപ്പെടുന്ന നെറ്റ്വർക്ക് നയം പ്രവേശനത്തെക്കുറിച്ചുള്ള തെളിവാണ്. അത് പാക്കറ്റുകളെക്കുറിച്ചുള്ള തെളിവല്ല, ഈ രണ്ട് പ്രസ്താവനകൾക്കിടയിലെ വിടവാണ് ഈ ജോലിയുടെ ഭൂരിഭാഗവും നടക്കുന്ന സ്ഥലം.
സെഷൻ യഥാർത്ഥത്തിൽ സ്വീകരിച്ച നയം കണ്ടെത്തുക
NPS ക്രമീകരിച്ച നെറ്റ്വർക്ക് നയങ്ങൾ വിലയിരുത്തുന്നു, വ്യവസ്ഥകൾ പൊരുത്തപ്പെടുന്ന ആദ്യ പ്രവർത്തനക്ഷമമായ നിയമം വിജയിക്കുന്നു. വ്യവസ്ഥകളിൽ ഉപയോക്താവിന്റെയോ കമ്പ്യൂട്ടറിന്റെയോ ഗ്രൂപ്പ് അംഗത്വം, കണക്ഷൻ തരം, സമയം, ഉപകരണ നില എന്നിവ ഉൾപ്പെടാം. അതിനാൽ പട്ടികയിൽ നേരത്തെയുള്ള വിശാല നയം, താഴെയുള്ള ഇടുങ്ങിയ നിയമം പരിഗണിക്കുന്നതിന് മുമ്പേ കണക്ഷൻ സ്വീകരിക്കുന്നു. ക്രമം ഇന്റർഫേസിന്റെ വിശദാംശമല്ല; ക്രമമാണ് നയം.
പട്ടിക ക്രമത്തിൽ വായിച്ച് പൊരുത്തപ്പെട്ടത് തിരിച്ചറിയുക, തുടർന്ന് അത് ഏത് ക്രമീകരണങ്ങൾ തിരികെ നൽകി എന്ന് രേഖപ്പെടുത്തുക. എഡിറ്ററിലെ ഗ്രൂപ്പ് പേരല്ല ഫലം; സെർവർ ലഭിച്ച അംഗീകാരമാണ് ഫലം. വിന്യാസം രണ്ടും ഉപയോഗിക്കുന്നിടത്ത് ഉപയോക്തൃ അംഗീകാരവും ഉപകരണ അംഗീകാരവും വേർതിരിച്ച് സൂക്ഷിക്കുക, കാരണം ടണൽ തുറക്കാൻ അനുവാദമുള്ള അക്കൗണ്ട് ഓരോ ആന്തരിക സേവനത്തിലും എത്തേണ്ട അക്കൗണ്ടല്ല.
RADIUS മറുപടി ഒരു നിർദ്ദേശമാണ്, ഫിൽട്ടറല്ല
Filter-Id ആട്രിബ്യൂട്ട് ഒരു ഫിൽട്ടർ പട്ടികയുടെ പേര് വഹിക്കുന്നു. എല്ലാ സ്വീകർത്താവും മനസ്സിലാക്കുന്ന കൈമാറ്റം ചെയ്യാവുന്ന പാക്കറ്റ് ഫിൽട്ടർ നിയമങ്ങളുടെ ഒരു കൂട്ടം ഇത് അയക്കുന്നില്ല, ഗേറ്റ്വേ ഒരിക്കലും നിർവചിക്കാത്ത ഒരു പേര് അയക്കുന്നത് ഒന്നും നിർവ്വഹിക്കുന്നുമില്ല. അതേ മുൻകരുതൽ VLAN ആട്രിബ്യൂട്ടുകൾക്കും ബാധകമാണ്: ഒരു ടണൽ സെഷൻ ഒരു VLAN-ന് നൽകുന്നത് അതിൽത്തന്നെ ആ ഉപയോക്താവിനുള്ള റൂട്ട് ചെയ്ത ആക്സസ് നിയമമല്ല.
ഇവിടെയാണ് NPS വശത്ത് പൂർണ്ണമായി തോന്നുന്ന ഡിസൈൻ നിശബ്ദമായി ഒന്നും ചെയ്യാത്തത്. ഏത് അംഗീകാര ആട്രിബ്യൂട്ടുകൾ പിന്തുണയ്ക്കുന്നു, സ്വീകർത്താവ് ഓരോന്നിനെയും എന്ത് ചെയ്യുന്നു എന്ന് ഗേറ്റ്വേ വിൽപ്പനക്കാരന്റെ രേഖകളിൽ നിന്ന് സ്ഥിരീകരിക്കുക, സ്റ്റാൻഡേർഡ് ആട്രിബ്യൂട്ട് പേര് സ്റ്റാൻഡേർഡ് പെരുമാറ്റം അർത്ഥമാക്കുന്നു എന്ന് അനുമാനിക്കുന്നതിന് പകരം.
നിർവ്വഹണം ട്രാഫിക് കടന്നുപോകുന്നിടത്ത് വയ്ക്കുക
ഉപയോക്താവിന്റെ പാക്കറ്റുകൾ പ്രോസസ്സ് ചെയ്യുന്ന ഗേറ്റ്വേക്ക് ഓരോ സെഷനും ഫിൽട്ടർ പ്രയോഗിക്കാം, ഒരു ഗ്രൂപ്പിനെ ഗേറ്റ്വേ നയത്തിലേക്ക് മാപ്പ് ചെയ്യാം, അല്ലെങ്കിൽ ഫയർവാൾ വ്യത്യസ്തമായി കാണുന്ന വേർതിരിച്ച പൂളിൽനിന്ന് സെഷന് ഒരു വിലാസം നൽകാം. ഇവയിലേതെങ്കിലും പ്രവർത്തിച്ചേക്കാം, അവ വ്യത്യസ്ത രീതികളിൽ പരാജയപ്പെടുന്നു. നയം എഴുതുന്നതിന് മുമ്പ് നിങ്ങളുടെ ഗേറ്റ്വേ ഏത് സംവിധാനത്തെ പിന്തുണയ്ക്കുന്നു എന്ന് നിർണ്ണയിക്കുക. തുടർന്ന് ആ സംവിധാനം ഇല്ലാത്തപ്പോൾ സെഷന് എന്ത് സംഭവിക്കുന്നു എന്ന് എഴുതുക, കാരണം നിശബ്ദതയാണ് ഡിഫോൾട്ട്.
ഉദ്ദേശിച്ച അനുമതി നാല് ഭാഗങ്ങളായി വിവരിക്കുക: ഉറവിട ഐഡന്റിറ്റി അല്ലെങ്കിൽ ഗ്രൂപ്പ്, ലക്ഷ്യസ്ഥാനം, പ്രോട്ടോക്കോൾ, പോർട്ട്. ഉപയോക്താവിന് യഥാർത്ഥത്തിൽ ആവശ്യമുള്ള ആശ്രിതത്വങ്ങൾ ചേർക്കുക, ഉദാഹരണത്തിന് DNS അല്ലെങ്കിൽ ഒരു പ്രാമാണീകരണ സേവനം, അല്ലാത്തപക്ഷം പരിശോധിക്കാൻ ആരും ചിന്തിക്കാത്ത ലോഗിൻ പ്രവാഹങ്ങൾ നിയന്ത്രണം തകർക്കും. യഥാർത്ഥത്തിൽ ഫിൽട്ടർ ചെയ്യുന്ന ഇന്റർഫേസിനെതിരെ നിയമം എഴുതുക, എഡിറ്ററിൽ യാദൃച്ഛികമായി തുറന്നിരിക്കുന്ന ഇന്റർഫേസിനെതിരെയല്ല.
വിലാസ പരിഭാഷണവും പരിഗണിക്കുക. താഴെയുള്ള ഫയർവാൾ ഓരോ ടണൽ ഉപയോക്താവിനും ഒരു പരിഭാഷിത ഉറവിട വിലാസം കണ്ടാൽ, ആ വിലാസത്തിൽനിന്ന് മാത്രം വ്യക്തികളെ വേർതിരിക്കാനാവില്ല, കഴിയുമെന്നപോലെ എഴുതിയ നിയമം നിഷ്പ്രയോജനമോ വളരെ വിശാലമോ ആകും.
ക്ലയന്റ് പ്രൊഫൈലുകൾ വിശ്വസിക്കാനാവാത്ത വശത്ത് ജീവിക്കുന്നു
നിർവ്വഹിത VPN പ്രൊഫൈലിന് റൂട്ടുകൾ, വിഭജിത ടണൽ നിയമങ്ങൾ അല്ലെങ്കിൽ ആപ്ലിക്കേഷൻ ഫിൽട്ടറുകൾ അയക്കാം, അവ മര്യാദയുള്ള ഉപകരണം എങ്ങനെ പെരുമാറുന്നു എന്ന് രൂപപ്പെടുത്തുന്നു. അവ സേവനത്തിനുള്ള സംരക്ഷണമല്ല, കാരണം ക്ലയന്റാണ് നിങ്ങൾ പരിമിതപ്പെടുത്താൻ ശ്രമിക്കുന്ന കക്ഷി. പ്രൊഫൈലിലെ ഒരു റൂട്ട് നീക്കം ചെയ്യുന്നതും അംഗീകാരമല്ല, കാരണം ക്ലയന്റിന് അതേ ലക്ഷ്യത്തിലേക്ക് മറ്റൊരു പാത ഉണ്ടായിരിക്കാം.
ക്ലയന്റ് ക്രമീകരണങ്ങളെ സൗകര്യമായും ഗേറ്റ്വേ ക്രമീകരണങ്ങളെ നിയന്ത്രണമായും കാണുക. രണ്ടും വിയോജിക്കുമ്പോൾ ഗേറ്റ്വേയാണ് ശരി, കാരണം പാക്കറ്റുകൾ കാണുന്നത് അതാണ്.
രണ്ട് അക്കൗണ്ടുകളിൽ സ്വീകരിച്ച്, പിന്നെ ക്രമത്തിൽ പിന്തുടരുക
വ്യത്യസ്ത ഉദ്ദേശിത അനുമതികളുള്ള രണ്ട് സാധാരണ പരീക്ഷണ അക്കൗണ്ടുകൾ സൃഷ്ടിക്കുക, പുതിയ സെഷനുകൾ സ്ഥാപിക്കുക, ഓരോന്നിനും ഫലപ്രദമായ ഗേറ്റ്വേ നയം പരിശോധിക്കുക. തുടർന്ന് ഒരു നിരുപദ്രവകരമായ അനുവദിച്ച പ്രവർത്തനവും പ്രത്യേകം നിഷേധിച്ച ഒരു ഉറവിടവും പരീക്ഷിക്കുക. പരാജയപ്പെട്ട ping തന്നെ വളരെ കുറച്ച് മാത്രമേ തെളിയിക്കുന്നുള്ളൂ, കാരണം ICMP ഫിൽട്ടർ ചെയ്യപ്പെടാം, അതിന് പിന്നിലെ TCP സേവനം സന്തോഷത്തോടെ ഉത്തരം നൽകുന്നു.
രണ്ട് അക്കൗണ്ടുകൾക്കും ഇപ്പോഴും വിശാല പ്രവേശനം ലഭിക്കുന്നുവെങ്കിൽ, ഒരു നിശ്ചിത ക്രമത്തിൽ പിന്തുടരുക: ഏത് നയം പൊരുത്തപ്പെട്ടു, മറുപടി ഏത് അംഗീകാരം വഹിച്ചു, ഗേറ്റ്വേ അതുപയോഗിച്ച് എന്ത് ചെയ്തു. സ്വീകർത്താവ് അവ നടപ്പാക്കുന്നു എന്ന് സ്ഥിരീകരിക്കുന്നതിന് മുമ്പ് കൂടുതൽ NPS ആട്രിബ്യൂട്ടുകൾ ചേർക്കുന്നതാണ് ചെറിയ അംഗീകാര പ്രശ്നത്തെ ഫലമില്ലാത്ത മാറ്റ ജാലകമാക്കി മാറ്റുന്ന വഴി.