RRAS VPN ക്ലയന്റുകൾക്ക് സ്വന്തം IPv4 പൂളും തിരികെയുള്ള വഴിയും വേണം

VPN ക്ലയന്റ് കണക്ട് ചെയ്ത് ഒരു വിലാസം സ്വീകരിക്കുന്നു, എന്നാൽ അതിന് ആവശ്യമായ LAN ഹോസ്റ്റിന് ഇപ്പോഴും മറുപടി നൽകാൻ കഴിയുന്നില്ല. Windows Routing and Remote Access ൽ VPN ക്ലയന്റുകളുടെ ആന്തരിക വിലാസം സർവറിന്റെ LAN അഡാപ്റ്ററിൽ നിന്ന് വേറിട്ട് ക്രമീകരിച്ച ഒരു പൂളിൽ നിന്നാണ് വരുന്നത്, കൂടാതെ LAN വശത്തിന് ആ പൂളിലേക്ക് തിരികെയുള്ള റൂട്ട് ആവശ്യമാണ്. രണ്ട് മാറ്റങ്ങൾ, ഒന്നല്ല, അവ വ്യത്യസ്ത രീതികളിൽ പരാജയപ്പെടുന്നു. പഴയ ശ്രേണികൾ പിൻവലിക്കുന്നതിന് മുമ്പ് വിലാസ പ്ലാനും തിരികെയുള്ള വഴിയും തെളിയിക്കപ്പെടാൻ അവ ക്രമത്തിൽ ചെയ്യുക.

കൺസോൾ തുറക്കുന്നതിന് മുമ്പ് ശ്രേണി റിസർവ് ചെയ്യുക

LAN, മറ്റ് VPN ശ്രേണികൾ അല്ലെങ്കിൽ സൈറ്റിലേക്ക് റൂട്ട് ചെയ്യുന്ന എന്തിനോടും ഓവർലാപ്പ് ചെയ്യാത്ത ഒരു പ്രിഫിക്സ് തിരഞ്ഞെടുക്കുക. പരിശോധനയ്ക്ക് /24 സൗകര്യപ്രദമായ വലുപ്പമാണ്, ആദ്യത്തെ ഉപയോഗയോഗ്യമായ ഭാഗം ക്ലയന്റുകൾക്ക് നൽകാം, ബാക്കി വളർച്ചയ്ക്കായി സ്വതന്ത്രമായി നിൽക്കും. കൺസോളിൽ ടൈപ്പ് ചെയ്യുന്നതിന് മുമ്പ് അത് അതിന്റെ ഉദ്ദേശ്യവും ഉടമയും സഹിതം എഴുതി വയ്ക്കുക. പിന്നീടുള്ള വിഭജനം പുനർനമ്പർ ചെയ്യാൻ നിർബന്ധിക്കാതിരിക്കാൻ ബ്ലോക്കിന്റെ ഇരു അറ്റത്തും ഇടം വിടുക.

കൺസോളിൽ മാത്രം ജീവിക്കുന്ന ഒരു വിലാസ പ്ലാൻ ഒരു പുനർനിർമ്മാണത്തിന്റെ അകലത്തിൽ കൂട്ടിയിടിയിൽ നിന്ന് നിൽക്കുന്നു. അത് വളരാനും സാധ്യതയുണ്ട്: ആരെങ്കിലും പിന്നീട് രണ്ടാമത്തെ ശ്രേണി ചേർക്കുന്നു, ആദ്യത്തേത് ആരും പരിശോധിക്കുന്നില്ല. പ്ലാൻ ചാറ്റ് ത്രെഡിൽ അല്ല, സർവർ ഡോക്യുമെന്റേഷന് അരികിൽ സൂക്ഷിക്കുക.

സർവറിന്റെ LAN അഡാപ്റ്റർ ഈ പൂൾ നിർവചിക്കുന്നില്ല. പൊതു ശ്രോതാവ് മാറ്റുന്നതോ LAN ലേക്ക് അഡാപ്റ്റർ ചേർക്കുന്നതോ തികച്ചും വേറെ എന്തോ ചെയ്യുന്നു. അതുകൊണ്ടാണ് ക്ലയന്റുകൾ കണക്ട് ചെയ്തിട്ടും തെറ്റായ സ്ഥലത്തുനിന്ന് വിലാസം സ്വീകരിക്കാൻ കഴിയുന്നത്. പൂൾ സർവറിന്റെ IPv4 ഗുണങ്ങളിൽ ജീവിക്കുന്നു, അഡാപ്റ്റർ പട്ടികയിൽ അല്ല.

രീതി മാറ്റുന്നത് ശ്രേണി ചേർക്കലല്ല

RRAS ന് ഒരു അനുവദന രീതിയും ശ്രേണികളുടെ ഒരു കൂട്ടവുമുണ്ട്. DHCP ൽ നിന്ന് സ്ഥിര പൂളിലേക്കുള്ള മാറ്റം രീതി മാറ്റമാണ്. സ്ഥിര പൂൾ ഇതിനകം സജീവമായിരിക്കെ മറ്റൊരു ബ്ലോക്ക് ചേർക്കുന്നത് ശ്രേണി മാറ്റമാണ്.

ഏതെങ്കിലും ഒന്ന് പ്രവർത്തിപ്പിക്കുന്നതിന് മുമ്പ് രണ്ട് പ്രവർത്തനങ്ങളും പ്രിവ്യൂ ചെയ്യുക, സർവറിന്റെ നിലവിലെ അവസ്ഥയുമായി ഏതാണ് യോജിക്കുന്നതെന്ന് വായിക്കുക:

Set-VpnIPAddressAssignment -IPAssignmentMethod StaticPool -IPAddressRange '10.250.50.10','10.250.50.100' -WhatIf
Add-VpnIPAddressRange -IPAddressRange '10.250.50.110','10.250.50.150' -WhatIf

സർവർ ഇപ്പോഴും DHCP അനുവദനയിലാണെങ്കിൽ രണ്ടാമത്തെ cmdlet പരാജയപ്പെടുന്നു അല്ലെങ്കിൽ ഉപയോഗശൂന്യമായ പൂൾ സൃഷ്ടിക്കുന്നു. ആദ്യത്തേത് നിലവിലുള്ള പൂൾ വികസിപ്പിക്കുന്നതിന് പകരം രീതി മാറ്റിസ്ഥാപിക്കുന്നു. ഏത് പ്രിവ്യൂവും ഒന്നും പ്രയോഗിക്കുന്നില്ല, അതിനാൽ യോജിക്കുന്നത് പ്രവർത്തിപ്പിക്കുക, തുടർന്ന് ഫലമായുണ്ടാകുന്ന പൂൾ കൺസോളിൽ സ്ഥിരീകരിക്കുക. സർവർ ഏത് അവസ്ഥയിലാണെന്ന് ഉറപ്പില്ലെങ്കിൽ IPv4 ഗുണ വിവര പേജിൽ അനുവദന രീതി വായിച്ച് ക്രമീകരിച്ച ശ്രേണികൾ ലിസ്റ്റ് ചെയ്യുക:

Get-VpnIPAddressRange

ശൂന്യമായ ശ്രേണി പട്ടികയുള്ള DHCP രീതി എന്നാൽ ആദ്യ പ്രിവ്യൂ പ്രയോഗിക്കുന്നു എന്നാണ്. നിലവിലുള്ള ശ്രേണിയുള്ള സ്ഥിര വിലാസ പൂൾ എന്നാൽ രണ്ടാമത്തേത് പ്രയോഗിക്കുന്നു എന്നാണ്.

ക്രമീകരണത്തിന് ആവശ്യമായേക്കാവുന്ന സേവന പുനരാരംഭം കണക്കിലെടുക്കുക, കണക്ട് ചെയ്ത ക്ലയന്റുകൾ ഉടനടി പുനർനമ്പർ ചെയ്യപ്പെടുമെന്ന് കരുതരുത്. പഴയ വിലാസം വീണ്ടും കണക്ട് ചെയ്യുന്നതുവരെ നിലനിർത്തുന്ന ക്ലയന്റ് സാധാരണമായി പെരുമാറുന്നു. വീണ്ടും കണക്ട് ചെയ്യൽ സ്വീകാര്യമായ ഒരു വിൻഡോയ്ക്ക് മാറ്റം ആസൂത്രണം ചെയ്യുക.

LAN ന് തിരികെയുള്ള റൂട്ട് വേണം

LAN 10.60.0.0/24 ഉം RRAS സർവർ അതിൽ 10.60.0.10 ഉം ആണെന്ന് കരുതുക. ആ LAN ലെ 10.250.50.0/24 ലെ ക്ലയന്റിന് മറുപടി നൽകുന്ന ഹോസ്റ്റിന് RRAS സർവർ വഴി പൂളിലേക്ക് ഒരു വഴി വേണം. ആ വഴിയില്ലെങ്കിൽ അഭ്യർത്ഥന എത്തുന്നു, മറുപടി മരിക്കുന്നു.

ഹോസ്റ്റിന്റെ സ്ഥിര ഗേറ്റ്വേ മറ്റൊരു റൗട്ടർ ആണെങ്കിൽ, ആ റൗട്ടർക്ക് VPN പ്രിഫിക്സിനുള്ള തിരികെയുള്ള റൂട്ട് വേണം. RRAS സർവറിലെ സ്ഥിര റൂട്ട് ഇവിടെ സഹായിക്കുന്നില്ല; തിരികെയുള്ള വഴി LAN ഗേറ്റ്വേ ഉള്ള ഉപകരണത്തിൽ ഉണ്ടായിരിക്കണം, അതിനാൽ സൈറ്റ് ഉപയോഗിക്കുന്നത് അനുസരിച്ച് അത് റൂട്ടിംഗ് പട്ടികയിലേക്കോ ചലനാത്മക റൂട്ടിംഗ് പ്രക്രിയയിലേക്കോ ചേർക്കുക.

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

പഴയത് പിൻവലിക്കുന്നതിന് മുമ്പ് പുതിയ പൂൾ ഒരു ഉപകരണത്തിൽ തെളിയിക്കുക

നിങ്ങൾ നിയന്ത്രിക്കുന്ന ഒരു അനുമതി എടുക്കുക, വീണ്ടും കണക്ട് ചെയ്ത് ക്ലയന്റ് സ്വീകരിച്ച പൂൾ വിലാസം വായിക്കുക. ആ ഒരു സംഖ്യ അനുവദനയെ റൂട്ടിംഗിൽ നിന്ന് വേർതിരിക്കുന്നു. തുടർന്ന് പേരുള്ള ഒരു ആപ്ലിക്കേഷൻ പ്രവർത്തിപ്പിക്കുക, തിരികെയുള്ള ട്രാഫിക് നിരീക്ഷിക്കുക, നിരസിക്കപ്പെട്ട് തുടരേണ്ട ഒരു ലക്ഷ്യം പരീക്ഷിക്കുക. മൂന്ന് നിരീക്ഷണങ്ങൾ, മൂന്ന് വ്യത്യസ്ത പരാജയ രീതികൾ.

പേര് റെസല്യൂഷന് സ്വന്തം പരിശോധന അർഹതയുണ്ട്: IP വഴിയുള്ള ആക്സസ് പ്രവർത്തിച്ചേക്കാം, എന്നാൽ ക്ലയന്റിന്റെ DNS ഇപ്പോഴും അതിന് എത്താൻ കഴിയാത്ത ഒരു റെസോൾവറിലേക്ക് ചൂണ്ടുന്നു. LAN ലെ DNS സർവറിലേക്ക് ക്ലയന്റിന് അങ്ങോട്ട് റൂട്ട് ഉണ്ടെങ്കിലും സർവർ പുതിയ ശ്രേണിയിൽ നിന്നുള്ള ചോദ്യങ്ങൾ സ്വീകരിക്കുന്നുവെങ്കിലും മാത്രമേ എത്താൻ കഴിയൂ. പൂൾ നീങ്ങുമ്പോൾ രണ്ടും സാധാരണ വീഴ്ചകളാണ്.

സജീവ സെഷനുകളും പരിപാലന പ്രക്രിയയും കണക്കിലെടുത്തതിന് ശേഷം മാത്രം പഴയ ശ്രേണികളും അവയുടെ ഒഴിവാക്കലുകളും പിൻവലിക്കുക. പുതിയ വിലാസത്തോടെ കണക്ട് ചെയ്ത ക്ലയന്റ് അനുവദന തെളിയിക്കുന്നു, ആക്സസ് നയമല്ല. അത് ഉപയോഗിച്ച അവസാന സെഷൻ കാലഹരണപ്പെടുന്നതുവരെ പഴയ ശ്രേണി രേഖപ്പെടുത്തി സൂക്ഷിക്കുക.

മൂന്ന് നിരീക്ഷണങ്ങളിലൂടെ ഫലം പരിശോധിക്കുക

അംഗീകാരത്തിന് മൂന്ന് വസ്തുതകൾ വേണം: ക്ലയന്റിന് പുതിയ പൂളിൽ നിന്ന് ഒരു വിലാസമുണ്ട്, LAN ഹോസ്റ്റിന് അതിൽ എത്തി മറുപടി ലഭിക്കും, നിരസിച്ച ലക്ഷ്യം ഇപ്പോഴും നിരസിക്കപ്പെട്ടതാണ്. ഓരോന്നിനും സ്വന്തം പരിശോധനയുണ്ട്, അതിനാൽ പരാജയം അനുവദന, റൂട്ടിംഗ് അല്ലെങ്കിൽ നയം എന്നിവയിലേക്ക് ചൂണ്ടുന്നു. അവ ആ ക്രമത്തിൽ പ്രവർത്തിപ്പിക്കുക.

ക്ലയന്റിൽ നിന്ന്, വിലാസവും ഒരു LAN ഹോസ്റ്റിലേക്കുള്ള റൂട്ടും സ്ഥിരീകരിക്കുക:

ipconfig | findstr /i "IPv4"
route print -4

LAN ഹോസ്റ്റിൽ നിന്ന്, ഒരേ ഘട്ടത്തിൽ തിരികെയുള്ള വഴിയും നയവും സ്ഥിരീകരിക്കുക. പിംഗ് പരാജയപ്പെട്ടാലും ആപ്ലിക്കേഷൻ പ്രവർത്തിക്കുന്നുവെങ്കിൽ, കാണാത്ത ഭാഗം റൂട്ട് അല്ല, ICMP നിയമമാകാനാണ് സാധ്യത. രണ്ടും പരാജയപ്പെട്ടാൽ, VPN എഡിറ്റ് ചെയ്യുന്നതിന് മുമ്പ് ഹോസ്റ്റിലെ റൂട്ട് വായിക്കുക. മൂന്ന് ഫലങ്ങളും മാറ്റ ടിക്കറ്റിൽ രേഖപ്പെടുത്തുക, അടുത്തയാൾ തെളിവിൽ നിന്ന് തുടങ്ങാൻ.