RRAS DHCP: പുതിയ വിലാസമോ അതോ കോൺഫിഗറേഷൻ ഓപ്ഷനുകൾ മാത്രമോ?

ക്യാപ്ചറിലെ DHCPACK, VPN ക്ലയന്റ് തന്റെ വിലാസം DHCP-യിൽ നിന്ന് ലഭിച്ചു എന്ന തെളിവായി വായിക്കുന്നത് തെറ്റാണ്. സാധാരണയായി അത് ഏതോ DHCP സന്ദേശത്തിന് ഉത്തരം ലഭിച്ചു എന്ന് മാത്രമാണ് തെളിയിക്കുന്നത്. Windows RRAS തന്റെ സ്വന്തം സ്റ്റാറ്റിക് പൂളിൽ നിന്ന് സെഷൻ വിലാസങ്ങൾ നൽകാം, അപ്പോഴും DHCP ബന്ധിപ്പിച്ച ക്ലയന്റിന് ഓപ്ഷനുകൾ നൽകുന്നു. ഏത് ജോലിയാണ് നടന്നിരുന്നതെന്ന് അഭ്യർത്ഥനയുടെ തരം പറയും.

ഒരേ സന്ദേശ തരം പങ്കിടുന്ന രണ്ട് ജോലികൾ

DHCP രണ്ട് വേറിട്ട കാര്യങ്ങൾ ചെയ്യുന്നു, അവ സന്ദേശ തരങ്ങൾ പങ്കിടുന്നു. ഒന്ന് വിലാസവും പാട്ടവും അനുവദിക്കുന്നത്. മറ്റൊന്ന് ഇതിനകം വിലാസമുള്ള ഹോസ്റ്റിലേക്ക് കോൺഫിഗറേഷൻ എത്തിക്കുന്നത്, അതിനെ RFC 2131 DHCPINFORM എന്ന് വിളിക്കുന്നു. രണ്ടാമത്തെ സന്ദർഭത്തിൽ ഉത്തരം ഓപ്ഷനുകൾ വഹിക്കുന്നു, പാട്ട കാലയളവ് വഹിക്കുന്നില്ല.

അതിനാൽ ACK ഉത്തരത്തിന്റെ തെളിവാണ്, അനുവദനത്തിന്റെ തെളിവല്ല. ഏത് ചോദ്യമാണ് ചോദിച്ചതെന്ന് അതിന് മുൻപുള്ള സന്ദേശം തീരുമാനിക്കുന്നു. ആദ്യം അഭ്യർത്ഥന വരി വായിക്കുക, ബാക്കി ട്രെയ്സ് സാധാരണയായി സ്വയം വിശദീകരിക്കും.

RRAS വിലാസം എവിടെ നിന്ന് നേടുന്നു

RRAS തന്റെ കോൺഫിഗർ ചെയ്ത IPv4 അനുവദന രീതിയിലൂടെ VPN വിലാസ തീരുമാനം കൈവശം വയ്ക്കുന്നു: DHCP സെർവർ അല്ലെങ്കിൽ സ്റ്റാറ്റിക് വിലാസ പൂൾ. പൂൾ സ്റ്റാറ്റിക് ആണെങ്കിൽ പൂൾ തന്നെയാണ് അനുവദിക്കുന്നത്, വേറെ DHCP സെർവറിലെ റിസർവേഷന് ആ സെഷനിൽ പറയാനുള്ളതില്ല. രണ്ട് സംവിധാനങ്ങളും ഒരു നെറ്റ്വർക്കിൽ ഒന്ന് മറ്റൊന്നിനെ നിയന്ത്രിക്കാതെ സഹവർത്തിക്കാം.

Get-Command -Module RemoteAccess *IPAddress*

വിലാസം പരിശോധിക്കുന്നതിന് മുൻപ് പ്രാബല്യത്തിലുള്ള അനുവദന രീതി കണ്ടെത്തുക. സ്റ്റാറ്റിക് പൂളാണെങ്കിൽ DHCP സ്കോപ്പ് നോക്കേണ്ട തെറ്റായ സ്ഥലമാണ്. മുകളിലെ കമാൻഡ് നിങ്ങൾ പ്രവർത്തിപ്പിക്കുന്ന പതിപ്പിൽ ലഭ്യമായ cmdlet-കൾ പട്ടികപ്പെടുത്തുന്നു, ക്രമീകരണം കണ്ടെത്താൻ അത് മതി.

ഉപയോക്തൃ ക്ലാസിന് തെളിയിക്കാനാകുന്നതും ആകാത്തതും

DHCP ഉപയോക്തൃ ക്ലാസ് ക്ലയന്റ് അയയ്ക്കുന്ന ഒരു സ്ട്രിംഗാണ്, സാക്ഷ്യപ്പെടുത്തിയ ഗ്രൂപ്പ് അംഗത്വമല്ല. ക്ലയന്റ് ഒന്ന് അയച്ച് സെർവർ അതിന് മേൽ നയം പൊരുത്തപ്പെടുത്തിയാലും, ആ ലേബൽ സ്ട്രിംഗ് എത്തി എന്ന് മാത്രം തെളിയിക്കുന്നു. RFC 3004, ഈ ഓപ്ഷൻ ക്ലാസിലുള്ള അവകാശം സാക്ഷ്യപ്പെടുത്തുന്നില്ല എന്ന് വ്യക്തമായി പറയുന്നു.

VPN ഉപയോക്തൃനാമം, സുരക്ഷാ-ഗ്രൂപ്പ് ഐഡന്റിഫയർ, ലാപ്ടോപ്പിന്റെ Ethernet വിലാസം എന്നിവ ആ അഭ്യർത്ഥനയിൽ ഉപയോഗയോഗ്യമായ രൂപത്തിൽ പ്രത്യക്ഷപ്പെടുമെന്ന് പ്രതീക്ഷിക്കരുത്. അവ സാക്ഷ്യപ്പെടുത്തലിന്റെയും ഡയറക്ടറിയുടെയും വസ്തുതകളാണ്, DHCP അഭ്യർത്ഥന രണ്ടും വഹിക്കുന്നില്ല. ആവശ്യകത അധികാരമുള്ള ആളുകളെ വേർതിരിക്കലാണെങ്കിൽ, ഐഡന്റിറ്റി യഥാർത്ഥത്തിൽ നിലനിൽക്കുന്ന VPN നയത്തിൽ അത് നടപ്പാക്കുക. ആ വേർതിരിവാണ് രണ്ട് സംവിധാനങ്ങളെ സ്വതന്ത്രമായി നിർത്തുന്നത്.

ACK അല്ല, തെളിവുകൾ താരതമ്യം ചെയ്യുക

ഒരു പാക്കറ്റ് വായിക്കുന്നതിന് പകരം തെളിവ് ശൃംഖല നിർമ്മിക്കുക. സെഷന് ലഭിച്ച വിലാസം, അഭ്യർത്ഥനയുടെ സന്ദേശ തരവും ഫീൽഡുകളും, സെർവർ തിരികെ നൽകിയ ഓപ്ഷനുകൾ, പിന്നീട് ക്ലയന്റിന്റെ യഥാർത്ഥ കോൺഫിഗറേഷൻ എന്നിവ രേഖപ്പെടുത്തുക. ഓരോ കണ്ണിയും വേറെ ചോദ്യത്തിന് ഉത്തരം നൽകുന്നു, കാണാത്ത കണ്ണിയാണ് യഥാർത്ഥ തകരാർ സാധാരണയായി ഇരിക്കുന്ന സ്ഥലം.

Get-DhcpServerv4OptionValue -ScopeId 10.90.0.0

വിലാസം RRAS പൂളിൽ നിന്നാണ് വന്നതെങ്കിൽ, DHCP റിസർവേഷൻ ഒന്നും വിശദീകരിക്കുന്നില്ല. ഓപ്ഷനുകൾ എത്തിയിട്ടും ക്ലയന്റ് അവ അവഗണിച്ചെങ്കിൽ, സെർവർ തന്റെ ജോലി ചെയ്തു, അടുത്ത സ്റ്റോപ്പ് ക്ലയന്റ് കോൺഫിഗറേഷനാണ്. ഈ രണ്ട് ഫലങ്ങളും വ്യക്തമായി താരതമ്യം ചെയ്യുക, ACK ഇനി അവ്യക്തമല്ല. ഓരോ അനുവദന രീതിയിൽ നിന്നും ഓരോന്ന്, രണ്ട് ട്രെയ്സുകൾ ഏത് ഡോക്യുമെന്റേഷനെക്കാളും വേഗത്തിൽ തർക്കം തീർക്കുന്നു.