Windows-ൽ VPN പ്രാദേശിക LAN തടയുന്നു: റൂട്ടോ ക്ലയന്റ് നയമോ?
Windows-ൽ പ്രാദേശിക LAN ആക്സസ് രണ്ട് വ്യത്യസ്ത കാരണങ്ങളാൽ തകരുന്നു: കാണാത്ത റൂട്ട്, അല്ലെങ്കിൽ subnet ഉപേക്ഷിക്കുന്ന ഗേറ്റ്‌വേ നയം. മൂന്ന് പരിശോധനകൾ ഏതെന്ന് പറയുന്നു.
നിങ്ങളുടെ സ്വന്തം മേശയിലെ പ്രിന്റർ, NAS അല്ലെങ്കിൽ ഡെവലപ്മെന്റ് ബോക്സ് ജോലി VPN ബന്ധിപ്പിക്കുന്ന നിമിഷം പ്രതികരിക്കുന്നത് നിർത്തുന്നു. ചിലപ്പോൾ ഒരു റൂട്ട് കമാൻഡ് അത് സെക്കൻഡുകളിൽ ശരിയാക്കുന്നു; ചിലപ്പോൾ അതേ റൂട്ട് ശരിയാണ്, പാക്കറ്റുകൾ എന്നിട്ടും അപ്രത്യക്ഷമാകുന്നു, അതായത് സമാന ലക്ഷണമുള്ള മറ്റൊരു പ്രശ്നം നിങ്ങൾ നോക്കുന്നു. തീരുമാനം മൂന്ന് ചോദ്യങ്ങളിൽ എത്തുന്നു, അവ തെറ്റായ ക്രമത്തിൽ ചോദിക്കുന്നതാണ് ആളുകൾ ഒരു വൈകുന്നേരം മുഴുവൻ റൂട്ടുകൾ മായ്ച്ച് വീണ്ടും ചേർക്കുന്നതിന് കാരണം.
ഏതെങ്കിലും കമാൻഡിന് മുമ്പ് മൂന്ന് ചോദ്യങ്ങൾ
ഒന്നാമത്: പ്രാദേശിക പ്രിഫിക്സിന് ഒരു എൻട്രി ഉണ്ടോ, അത് ഭൗതിക അഡാപ്റ്ററിലേക്ക് ചൂണ്ടുന്നുണ്ടോ? രണ്ടാമത്: ബന്ധിപ്പിക്കുമ്പോൾ ക്ലയന്റ് ഗേറ്റ്‌വേയിൽ നിന്ന് പ്രാദേശിക നെറ്റ്‌വർക്കിന് അനുമതിയോ നിരാകരണമോ ലഭിക്കുന്നുണ്ടോ? മൂന്നാമത്: നിങ്ങൾക്ക് LAN-ലേക്ക് പുറത്തേക്കുള്ള ആക്സസ് മാത്രം വേണോ, അതല്ലെങ്കിൽ ഇന്റർനെറ്റിലുള്ള എന്തെങ്കിലും നിങ്ങളുടെ മെഷീനിൽ പ്രവർത്തിക്കുന്ന ഒരു സേവനത്തിലേക്കും എത്തണോ?
ആദ്യ ചോദ്യം റൂട്ടിംഗ് തകരാറിനെ ഫിൽട്ടറിംഗ് തകരാറിൽ നിന്ന് വേർതിരിക്കുന്നു. രണ്ടാമത്തേത് റൂട്ട് പരിഹാരത്തിന് പ്രവർത്തിക്കാൻ അനുമതിയുണ്ടോ എന്ന് പറയുന്നു. മൂന്നാമത്തേത് പരിഹാരം മാറ്റുന്നു: റൂട്ട് പുറത്തേക്കുള്ള ട്രാഫിക് ശരിയാക്കുന്നു, അതേസമയം എത്തിച്ചേരാനാകാത്ത ഇൻബൗണ്ട് സേവനം സാധാരണയായി ലിസണർ ബൈൻഡിംഗിന്റെയും മടക്കപ്പാതയുടെയും പ്രശ്നമാണ്, റൂട്ട് അത് കൂടുതൽ വഷളാക്കുന്നു.
| What you see | What it points at |
|---|---|
| No local prefix in the table | Missing route |
| Correct prefix, no reply | Client filter or gateway policy |
| Works by IP, fails by name | Resolver changed by the tunnel |
| Inbound service dies, outbound fine | Return path or listener binding |
ചോദ്യം ഒന്ന്: റൂട്ട്, ഫിൽട്ടർ അല്ലെങ്കിൽ പേര്
എന്തെങ്കിലും ചേർക്കുന്നതിന് മുമ്പ് പട്ടിക വായിക്കുക. ഇന്റർഫേസ് ഇൻഡക്സ് പ്രധാനമാണ്, കാരണം താഴെയുള്ള ഓരോ റൂട്ട് കമാൻഡും അതിൽ ഉറപ്പിച്ചിരിക്കുന്നു:
route print -4
Get-NetRoute -DestinationPrefix 192.168.1.0/24 | Format-Table InterfaceIndex,NextHop,RouteMetricനേരിട്ട് ബന്ധിപ്പിച്ച subnet ടണൽ ഉയർന്നിരിക്കുമ്പോഴും സാധാരണയായി ഓൺ-ലിങ്ക് റൂട്ട് നിലനിർത്തുന്നു, അതിനാൽ എൻട്രി നിലനിൽക്കാം, ട്രാഫിക് എന്നിട്ടും പരാജയപ്പെടാം. ആ സംയോജനം റൂട്ടിംഗിന് ശേഷം പ്രവർത്തിക്കുന്ന ഫിൽട്ടറിന്റെ ഒപ്പമാണ്, കൂടാതെ കൂടുതൽ നിർദ്ദിഷ്ടമായ രണ്ടാമത്തെ റൂട്ട് ഒന്നും മാറ്റാത്ത സന്ദർഭവുമാണ്.
വിലാസം അനുസരിച്ചും പേര് അനുസരിച്ചും വെവ്വേറെ പരിശോധിക്കുക. ping 192.168.1.50 പ്രതികരിക്കുകയും net view 192.168.1.50 പ്രതികരിക്കാതിരിക്കുകയും ചെയ്താൽ, റൂട്ടിംഗ് പട്ടിക ഒരിക്കലും പ്രശ്നമായിരുന്നില്ല: ടണൽ റിസോൾവർ മാറ്റി, പ്രാദേശിക പേര് ഇനി പരിഹരിക്കപ്പെടുന്നില്ല. അതിനായി റൂട്ട് ചേർക്കുന്നത് പാഴ്‌വേലയാണ്.
ചോദ്യം രണ്ട്: ഗേറ്റ്‌വേ പ്രാദേശിക LAN ആക്സസ് അനുവദിക്കുന്നുണ്ടോ?
വാണിജ്യ ക്ലയന്റ് റൂട്ടുകളിൽ കൂടുതൽ ഇൻസ്റ്റാൾ ചെയ്യുന്നു. ബന്ധിപ്പിക്കുമ്പോൾ അതിന് ഒരു നയം ലഭിക്കുന്നു, ആ നയത്തിൽ പ്രാദേശിക നെറ്റ്‌വർക്കിനുള്ള വ്യക്തമായ അനുമതി ഉൾപ്പെടാം. Cisco IPsec വിന്യാസങ്ങളിൽ ഗ്രൂപ്പ് നയം split-tunneling ക്രമീകരണവും പ്രാദേശിക LAN ആക്സസിനുള്ള പ്രത്യേക ഫ്ലാഗും വഹിക്കുന്നു; ക്ലയന്റിലെ ചെക്ക്ബോക്സ് ഗേറ്റ്‌വേ നിരസിക്കാവുന്ന ഒരു അഭ്യർത്ഥനയാണ്. AnyConnect-ൽ പ്രൊഫൈൽ split-ന്റെ ഉൾപ്പെടുത്തൽ, ഒഴിവാക്കൽ ലിസ്റ്റുകളും അതേ അനുമതിയും നിയന്ത്രിക്കുന്നു. Windows RRAS-ൽ തത്തുല്യമായവ പ്രൊഫൈലിലെ ഡിഫോൾട്ട് ഗേറ്റ്‌വേ ഓപ്ഷനും സർവർ നൽകുന്ന സ്റ്റാറ്റിക് റൂട്ടുകളുമാണ്.
ഫ്ലാഗ് ഓഫ് ആയിരിക്കുമ്പോൾ, രേഖപ്പെടുത്തിയ പെരുമാറ്റം എന്നത് സാധുവായ, കൂടുതൽ നിർദ്ദിഷ്ടമായ റൂട്ട് ഉണ്ടായിരുന്നിട്ടും നേരിട്ട് ബന്ധിപ്പിച്ച subnet-ലേക്കുള്ള ട്രാഫിക് ക്ലയന്റ് തടയുന്നു എന്നതാണ്. അതുകൊണ്ടാണ് ക്ലയന്റിന്റെ ഉടമസ്ഥതയില്ലാത്ത റൂട്ടുകളും ചേർത്ത കുറച്ച് സെക്കൻഡുകൾക്ക് ശേഷം അപ്രത്യക്ഷമാകാം: ക്ലയന്റ് പറഞ്ഞ അവസ്ഥ വീണ്ടും നിർമ്മിക്കുകയാണ്, നിങ്ങളോട് പോരാടുകയല്ല.
ക്ലയന്റ് ലോഗ് ബന്ധിപ്പിക്കുമ്പോഴുള്ള തീരുമാനം രേഖപ്പെടുത്തുന്നു, അത് വായിക്കുന്നത് മെഷീനിലെ ഏതെങ്കിലും പരീക്ഷണത്തേക്കാൾ വേഗമാണ്. ലോഗ് പ്രാദേശിക ആക്സസ് തടഞ്ഞിരിക്കുന്നു എന്ന് പറഞ്ഞാൽ, നിർത്തുക: ഒരു കമാൻഡ്-ലൈൻ പരിഹാരവും അതിനെ അതിജീവിക്കില്ല, ബാക്കിയുള്ള വഴികൾ നയം മാറ്റുന്നത്, ടണലിലൂടെ വിഭവത്തിൽ എത്തുന്നത്, അല്ലെങ്കിൽ ക്ലയന്റിനെ വെർച്വൽ മെഷീനിൽ പാർപ്പിച്ച് ഹോസ്റ്റിനെ പ്രാദേശിക നെറ്റ്‌വർക്കിൽ വിടുന്നത് എന്നിവയാണ്.
ചോദ്യം മൂന്ന്: ഏത് ദിശയാണ് നിങ്ങൾക്ക് വേണ്ടത്?
അടുത്തുള്ള ഉപകരണത്തിലേക്കുള്ള പുറത്തേക്കുള്ള ട്രാഫിക് റൂട്ടിംഗ് ചോദ്യമാണ്. LAN പ്രിഫിക്സ് പ്രാദേശിക ഗേറ്റ്‌വേയിലേക്ക് ടണലിന്റെ ഡിഫോൾട്ട് റൂട്ടിനെ തോൽപ്പിക്കാൻ മതിയായ താഴ്ന്ന മെട്രിക് ഉപയോഗിച്ച് ചൂണ്ടിക്കാണിക്കുക:
route add 192.168.1.0 mask 255.255.255.0 192.168.1.1 metric 1 if 12
route add 192.168.1.50 mask 255.255.255.255 192.168.1.1 -pരണ്ടാമത്തെ രൂപം ഒരു ഉപകരണത്തെ പിൻ ചെയ്യുന്നു, ഒരു വിലാസം മാത്രമാണ് മുഴുവൻ ആവശ്യകതയെങ്കിൽ നിങ്ങൾ ആഗ്രഹിക്കുന്നത് അതാണ്. netsh തത്തുല്യം അതേ തീരുമാനം ഇൻഡക്സിന് പകരം ഇന്റർഫേസ് പേരിൽ രേഖപ്പെടുത്തുന്നു:
netsh interface ipv4 add route prefix=192.168.1.0/24 interface=12 nexthop=192.168.1.1 store=persistentവിലാസവും മാസ്കും പൊരുത്തപ്പെടാത്തപ്പോൾ റൂട്ട് കമാൻഡുകൾ പാരാമീറ്റർ തെറ്റാണ് എന്നതോടെ പരാജയപ്പെടുന്നു, ഉദാഹരണത്തിന് /24 മാസ്കുള്ള ഹോസ്റ്റ് വിലാസം. subnet റൂട്ടിന് നെറ്റ്‌വർക്ക് വിലാസവും ഒരു ഹോസ്റ്റിന് ഹോസ്റ്റ് മാസ്കും ഉപയോഗിക്കുക.
ഇൻബൗണ്ട് വ്യത്യസ്തമാണ്. അതേ മെഷീനിലെ VNC അല്ലെങ്കിൽ SSH സർവർ, ഇൻകമിംഗ് കണക്ഷനുള്ള മറുപടികൾ VPN ഗേറ്റ്‌വേയിലൂടെ പുറത്തുപോയി ഒരിക്കലും മടങ്ങിവരാത്തപ്പോൾ എത്തിച്ചേരാനാകാത്തതാകുന്നു. റൂട്ടുകൾ തൊടുന്നതിന് മുമ്പ് സേവനം എന്തിൽ കേൾക്കുന്നുവെന്ന് പരിശോധിക്കുക:
netstat -ano | findstr :5900ഒരു നിർദ്ദിഷ്ട വിലാസത്തിലേക്ക് ബന്ധിച്ച ലിസണർ മറ്റേ ഇന്റർഫേസിൽ പ്രതികരിക്കില്ല. അതിനെ എല്ലാ ഇന്റർഫേസുകളിലേക്കും ബന്ധിക്കുന്നത് ബോധപൂർവമുള്ള തീരുമാനമാണ്, നിങ്ങൾ വിശ്വസിക്കുന്ന നെറ്റ്‌വർക്കിലേക്ക് പരിമിതപ്പെടുത്തിയ ഫയർവാൾ നിയമത്തോടൊപ്പം എടുക്കുന്നത്. അതിനുശേഷം മാത്രമാണ് റൂട്ട് പരിഹാരം മടക്കപ്പാത പുനഃസ്ഥാപിക്കുന്നത്.
പൊരുത്തപ്പെടുന്ന ഏറ്റവും ചെറിയ മാറ്റം പ്രയോഗിക്കുക
മറ്റൊരു സാധാരണ നടപടി IPv4 വിപുലമായ ഗുണങ്ങളിൽ “വിദൂര നെറ്റ്‌വർക്കിൽ ഡിഫോൾട്ട് ഗേറ്റ്‌വേ ഉപയോഗിക്കുക” എന്നതിന്റെ ടിക്ക് നീക്കം ചെയ്യുന്നതാണ്. ഇത് ഇന്റർനെറ്റ് ട്രാഫിക് പ്രാദേശികമായി നിലനിർത്തുന്നു, പക്ഷേ ഒരേസമയം രണ്ട് കാര്യങ്ങൾ ചെയ്യുന്നു: VPN ഡിഫോൾട്ട് പാതയല്ലാതാകുന്നു, ഒപ്പം ക്ലയന്റ് വിദൂര നെറ്റ്‌വർക്കിനുള്ള റൂട്ടുകൾ, multicast ഉൾപ്പെടെ, സ്വീകരിക്കുന്നത് നിർത്തുന്നു. ടിക്ക് നീക്കിയാൽ, ഓരോ ക്ലയന്റിനും ആവശ്യമായ നിർദ്ദിഷ്ട വിദൂര പ്രിഫിക്സുകൾ സർവർ തള്ളിയില്ലെങ്കിൽ വിദൂര LAN അപ്രത്യക്ഷമാകും.
ആ അസമമിതിയാണ് ജോലിയുടെ ക്രമം തീരുമാനിക്കുന്നത്. വിദൂര വശം പൂർണ്ണമായി എത്തിച്ചേരാവുന്നതായി തുടരണമെങ്കിൽ, സർവറിൽ നിന്ന് വിദൂര subnet-കൾ തള്ളുക, പ്രാദേശിക ഡിഫോൾട്ട് അതേപടി വിടുക. സർവർ മാറ്റാൻ കഴിയില്ലെങ്കിൽ, ടണൽ അനുവദിച്ച വിലാസത്തിലൂടെ വിദൂര പ്രിഫിക്സിലേക്ക് സ്ഥിരമായ റൂട്ട് ചേർക്കുക, route print ഉപയോഗിച്ച് പ്രിഫിക്സ് VPN ഇന്റർഫേസിലേക്കും ഡിഫോൾട്ട് ഇപ്പോഴും ഭൗതിക ഗേറ്റ്‌വേയിലേക്കും ചൂണ്ടുന്നുവെന്ന് പരിശോധിക്കുക.
തുടർന്ന് പരിഹാരം വീണ്ടും ബന്ധിപ്പിക്കുന്നതിനെ അതിജീവിക്കുന്നുവെന്ന് ഉറപ്പാക്കുക, കാരണം സ്ഥിരമല്ലാത്ത റൂട്ടുകൾ അഡാപ്റ്ററിനൊപ്പം മരിക്കുന്നു, ഓരോ ബന്ധിപ്പിക്കലിനും ശേഷം പ്രവർത്തിക്കുന്ന സ്ക്രിപ്റ്റാണ് അവയ്ക്ക് സത്യസന്ധമായ സ്ഥലം. അതേ സെഷനിൽ ഒരു പ്രാദേശിക ഉപകരണവും ഒരു വിദൂര വിഭവവും പരിശോധിക്കുക, ഡിസ്കണക്ട് ചെയ്യുക, വീണ്ടും ബന്ധിപ്പിക്കുക, വീണ്ടും പരിശോധിക്കുക. റൂട്ട് ശരിയായി തോന്നുമ്പോഴും പ്രാദേശിക ഉപകരണം വീണ്ടും പരാജയപ്പെട്ടാൽ, ചോദ്യം രണ്ടിലേക്ക് മടങ്ങുക: ക്ലയന്റ് ഫിൽട്ടർ ചെയ്യുകയാണ്, ഉത്തരം നയം മാറ്റുന്നതാണ്, രണ്ടാമത്തെ മത്സര റൂട്ടല്ല.