സ്ഥിരമായ VPN ക്ലയന്റ് വിലാസത്തിനുള്ള RADIUS Framed-IP-Address

RADIUS ഒരു നിർദ്ദിഷ്ട ഉപയോക്താവിന് വിലാസത്തോടെ മറുപടി നൽകാം; ടണൽ അത് യഥാർത്ഥത്തിൽ സ്വീകരിക്കുന്നുണ്ടോ എന്നത് ഗേറ്റ്‌വേയെ ആശ്രയിച്ചിരിക്കുന്നു. തിരികെ നൽകിയതും പ്രയോഗിച്ചതും തമ്മിലുള്ള ഈ വിടവിലാണ് മിക്ക സ്ഥിര വിലാസ പദ്ധതികളും പരാജയപ്പെടുന്നത്. പരീക്ഷണ മറുപടിയിലെ ഒരു ആട്രിബ്യൂട്ട് സർവറിന് അത് അയയ്ക്കാമെന്ന് തെളിയിക്കുന്നു, റിമോട്ട് ആക്സസ് സേവനം അത് പ്രയോഗിക്കുന്നു എന്നല്ല. ചുവടെയുള്ള ക്രമം വിലാസം ഫയർവാൾ നിയമങ്ങളിൽ എത്തുന്നതിന് മുമ്പ് രണ്ട് പകുതികളും പരിശോധിക്കുന്നു.

വിലാസം ഏത് പാളത്തിന്റേതാണെന്ന് തീരുമാനിക്കുക

റിമോട്ട് ആക്സസ് ഗേറ്റ്‌വേകൾക്ക് സാധാരണയായി പ്രാദേശിക പൂൾ ഉണ്ട്, പലതിനും ഓതന്റിക്കേഷൻ മറുപടിയിൽ നിന്നും വിലാസം സ്വീകരിക്കാം. ഏത് വിജയിക്കുമെന്നത് പ്ലാറ്റ്ഫോം, പ്രോട്ടോക്കോൾ, സേവന കോൺഫിഗറേഷൻ എന്നിവയെ ആശ്രയിച്ചിരിക്കുന്നു, അതിനാൽ ഉപയോഗത്തിലുള്ള കൃത്യമായ പതിപ്പിനുള്ള മുൻഗണനാ നിയമം വായിക്കുക. പ്രാദേശിക പൂളിന് മുൻഗണനയുള്ളിടത്ത് ആട്രിബ്യൂട്ട് കേവലം അലങ്കാരമാണ്, ക്ലയന്റ് ഏതായാലും ക്രമരഹിതമായ വിലാസത്തിൽ എത്തുന്നു. തീരുമാനം എഴുതിവയ്ക്കുക, തിരികെ നൽകിയ മൂല്യം പൂൾ പരിധിക്കുള്ളിൽ തന്നെയായിരിക്കണമോ അതിന് പുറത്തും ആകാമോ എന്നത് ഉൾപ്പെടെ.

RFC 2865 Framed-IP-Address ഉപയോക്താവിനായി കോൺഫിഗർ ചെയ്യേണ്ട വിലാസമായി നിർവചിക്കുന്നു, ഒരു പ്രത്യേക ഗേറ്റ്‌വേ അതിനെ മാനിക്കാനുള്ള സന്നദ്ധതയെക്കുറിച്ച് ഒന്നും പറയുന്നുമില്ല. മുൻഗണനയുടെ കാര്യത്തിൽ നിർമ്മാതാവിന്റെ രേഖകൾക്കാണ് അധികാരം, ആട്രിബ്യൂട്ടിന്റെ നിർവചനത്തിനല്ല.

പരീക്ഷണ അഭ്യർത്ഥന അയച്ച് മറുപടി വായിക്കുക

ആദ്യം സർവർ വേർതിരിച്ച് പരിശോധിക്കുക, എന്നാൽ കാണാത്ത ആട്രിബ്യൂട്ടിനെ ഗേറ്റ്‌വേ പ്രശ്നമായി തെറ്റിദ്ധരിക്കില്ല. radtest ഒരു Access-Request അയച്ച് തിരികെ വരുന്ന ആട്രിബ്യൂട്ടുകൾ പ്രിന്റ് ചെയ്യുന്നു.

radtest alice 'S3cret' 127.0.0.1 0 testing123

Access-Accept-ൽ Framed-IP-Address തിരയുക, മൂല്യം ഉദ്ദേശിച്ചതാണെന്നും ബാക്കപ്പ് നിയമത്തിൽ നിന്നുള്ള പൂൾ വിലാസമല്ലെന്നും ഉറപ്പാക്കുക. ആട്രിബ്യൂട്ട് ഇല്ലാത്തപ്പോൾ ഉപയോക്തൃ എൻട്രിയോ അധികാര നയമോ പൊരുത്തപ്പെടുന്നില്ല, സർവർ ഒരിക്കലും അയയ്ക്കാത്തത് ഗേറ്റ്‌വേ ക്രമീകരണത്തിന് നൽകാനാകില്ല. മറുപടി ഒരു നിർദ്ദിഷ്ട നിയമവുമായി ബന്ധിപ്പിക്കാൻ ബുദ്ധിമുട്ടാണെങ്കിൽ സർവർ ഡീബഗ് മോഡിൽ പ്രവർത്തിക്കുമ്പോൾ അഭ്യർത്ഥന ആവർത്തിക്കുക. ഷെൽ ചരിത്രത്തിൽ നിന്നും ടിക്കറ്റുകളിൽ നിന്നും പങ്കിട്ട രഹസ്യം അകറ്റി നിർത്തുക, കാരണം മുകളിലെ പ്ലെയ്സ്‌ഹോൾഡർ ലോഗിൻ ക്രെഡൻഷ്യലല്ല.

ഗേറ്റ്‌വേ മൂല്യത്തെ മാനിച്ചുവെന്ന് ഉറപ്പാക്കുക

ശരിയായ മറുപടി കരാറിന്റെ പകുതി മാത്രമാണ്. ടണൽ ഇന്റർഫേസിൽ പ്രത്യക്ഷപ്പെടുന്ന വിലാസമാണ് പ്രധാന നിരീക്ഷണം, അത് ഗേറ്റ്‌വേ കോൺഫിഗറേഷനിൽ നിന്ന് അനുമാനിക്കുന്നതിന് പകരം ക്ലയന്റിൽ വായിക്കുന്നു.

ip -4 addr show tun0

ആ വിലാസം Access-Accept-ലെ ആട്രിബ്യൂട്ടുമായി താരതമ്യം ചെയ്യുക. പൊരുത്തക്കേട് എന്നാൽ ഗേറ്റ്‌വേ മൂല്യം അവഗണിച്ചു അല്ലെങ്കിൽ വീണ്ടും എഴുതി എന്നാണ്, ഇത് ആദ്യ വിഭാഗത്തിലെ മുൻഗണനാ ചോദ്യം വീണ്ടും തുറക്കുന്നു. ഒരിക്കൽ കൂടി ബന്ധിപ്പിക്കുക, കാരണം ആദ്യ ശ്രമത്തിൽ മാത്രം പ്രവർത്തിക്കുന്ന റിസർവേഷൻ സാധാരണയായി കാലഹരണപ്പെട്ട സെഷനെയോ മുൻ കണക്ഷൻ ഇപ്പോഴും കൈവശം വയ്ക്കുന്ന ലീസിനെയോ സൂചിപ്പിക്കുന്നു. ഗേറ്റ്‌വേ പതിപ്പും പ്രോട്ടോക്കോളും ഫലത്തിന് സമീപം രേഖപ്പെടുത്തുക, അടുത്ത വ്യക്തിക്ക് പെരുമാറ്റം പതിപ്പ്-നിർദ്ദിഷ്ടമാണോ എന്ന് അറിയാൻ.

ഏകകാലികതയ്ക്കും റദ്ദാക്കലിനും പദ്ധതിയിടുക

ഒരു ഉപയോക്തൃനാമം രണ്ട് ഉപകരണങ്ങളിൽ ഒരു വിലാസത്തിലേക്ക് മാപ്പ് ചെയ്യാനാകില്ല, ഗേറ്റ്‌വേ ലോഗിൻ അല്ലാതെ മറ്റെന്തെങ്കിലും കൊണ്ട് സെഷനുകളെ വേർതിരിക്കുന്നില്ലെങ്കിൽ. മാപ്പിംഗ് ഒരു വ്യക്തിക്കോ രജിസ്റ്റർ ചെയ്ത ഉപകരണത്തിനോ സർട്ടിഫിക്കറ്റ് ഐഡന്റിറ്റിക്കോ ഉള്ളതാണോ എന്ന് തീരുമാനിക്കുക, ആ തിരഞ്ഞെടുപ്പ് നയ സംഭരണിയിൽ വ്യക്തമാക്കുക. രണ്ടാമത്തെ ഏകകാലിക ക്ലയന്റ് പരീക്ഷിച്ച് അനുവദിച്ച രണ്ട് വിലാസങ്ങളും താരതമ്യം ചെയ്യുക, കാരണം ഇവിടത്തെ കൂട്ടിയിടി പിന്നീട് റൂട്ടിംഗ് പിശകായി വീണ്ടും പ്രത്യക്ഷപ്പെടുന്നു. അതേ ജാഗ്രത റദ്ദാക്കൽ പദ്ധതിയിലും വേണം, കാരണം പഴയ ഫയർവാൾ നിയമങ്ങൾ ഇപ്പോഴും അതിനെ പരാമർശിക്കുമ്പോൾ വീണ്ടും അനുവദിച്ച വിലാസം അധികാര പിശകായി മാറുന്നു.

സ്ഥിര വിലാസനിർണ്ണയം നിയമങ്ങളും ലോഗുകളും ലളിതമാക്കുന്നു, പക്ഷേ പാക്കറ്റ് ആരു നിർമ്മിച്ചു എന്ന് ഒരിക്കലും തെളിയിക്കുന്നില്ല. ആ വിലാസം പിന്നീട് മറ്റൊരു സെഷനിലേക്ക് പോകുമ്പോൾ ഓതന്റിക്കേഷനും ലക്ഷ്യ അധികാരവും ഇപ്പോഴും പ്രധാനമാണ്.