VPN ക്ലൈന്റ് മോഡിൽ റൗട്ടർ: LAN ഉപകരണങ്ങൾ എന്തുകൊണ്ട് അപ്രത്യക്ഷമാകുന്നു
റൗട്ടർ VPN ക്ലൈന്റ് മോഡിലേക്ക് മാറിയതിന് ശേഷം LAN ഉപകരണങ്ങൾ അപ്രത്യക്ഷമാകുന്നു: ആദ്യം ഫോർവേഡ് പാത്തിലെ പരിശോധനാ സവിശേഷത, പിന്നീട് ഫേംവെയർ മാറ്റിയ LAN പരിധി പരിശോധിക്കുക.
ക്ലൈന്റ് മോഡ് തന്നെ LAN ആക്സസ് കൊല്ലുന്നു എന്ന വിശ്വാസം ആളുകളെ തെറ്റായ ക്രമീകരണ മെനുവിലേക്ക് അയക്കുന്നു, യഥാർത്ഥ കാരണങ്ങൾ സാധാരണയായി രണ്ടാണ്. ടണൽ LAN ബ്രിഡ്ജ് നീക്കം ചെയ്യുന്നില്ല, വയർ, വയർലെസ് ക്ലൈന്റുകൾ പരസ്പരം എത്തുന്നത് തടയുന്നുമില്ല. പ്രാദേശിക ആക്സസ് തകർക്കുന്നത് റൗട്ടറിന്റെ ഫോർവേഡ് പാത്തിലുള്ള പരിശോധനാ സവിശേഷതയോ ഫേംവെയർ മാറ്റിയപ്പോൾ നീങ്ങിയ LAN വിലാസ പരിധിയോ ആണ്. രണ്ടും ഒരേ പരാതി ഉണ്ടാക്കുന്നു, VPN പ്രൊഫൈൽ വീണ്ടും ഇൻസ്റ്റാൾ ചെയ്ത് ഒന്നും ശരിയാകുന്നുമില്ല.
കെട്ടുകഥ, ക്ലൈന്റ് മോഡ് യഥാർത്ഥത്തിൽ മാറ്റുന്നത്
ക്ലൈന്റ് മോഡ് ഒരു ടണൽ ഇന്റർഫേസും അതിലൂടെ പോകുന്ന സ്ഥിരസ്ഥിതി റൂട്ടും ചേർക്കുന്നു, തുടർന്ന് LAN ട്രാഫിക് ആ ടണലിലേക്ക് ഫോർവേഡ് ചെയ്യുന്നു. വയർ പോർട്ടുകളും വയർലെസ് റേഡിയോകളും തമ്മിലുള്ള ബ്രിഡ്ജ് അതേപടി നിൽക്കുന്നു, പ്രാദേശിക സ്വിച്ചിംഗും. മാറുന്നത് നയമാണ്: ഏത് ട്രാഫിക് ഫോർവേഡ് ചെയ്യുന്നു, എവിടെ വിവർത്തനം ചെയ്യുന്നു, ക്ലൈന്റുകൾക്ക് ഏത് റിസോൾവർ ലഭിക്കുന്നു.
ഈ വ്യത്യാസം പ്രധാനമാണ്, കാരണം തകർന്ന LAN സാധാരണയായി ആ മൂന്ന് നയങ്ങളിലൊന്ന് മാറി എന്നാണ് അർത്ഥമാക്കുന്നത്, റൗട്ടർ സ്വിച്ച് ആകുന്നത് നിർത്തി എന്നല്ല. സ്വന്തം അഡ്മിൻ പേജിന് ഇപ്പോഴും ഉത്തരം നൽകുന്ന റൗട്ടർ LAN ഇന്റർഫേസ് ജീവനോടെയുണ്ടെന്നതിന്റെ തെളിവാണ്. ഒന്നിനും ഉത്തരം നൽകാത്ത റൗട്ടറിന് മറ്റൊരു പ്രശ്നമുണ്ട്, ഉദാഹരണത്തിന് മാറിയ LAN വിലാസം അല്ലെങ്കിൽ തെറ്റായ സബ്നെറ്റിലുള്ള ക്ലൈന്റ്.
അതിനാൽ ഉപയോഗപ്രദമായ ആദ്യ ചുവട് ഏത് ലെയർ തകർന്നു എന്ന് കണ്ടെത്തുകയാണ്, നിങ്ങൾ സംശയിക്കുന്ന ലെയർ മാറ്റുന്നതല്ല.
ഒരു ക്രമീകരണം തൊടുന്നതിന് മുമ്പ് മൂന്ന് ലക്ഷ്യങ്ങൾ പരിശോധിക്കുക
വയർ ക്ലൈന്റിൽ നിന്ന് മൂന്ന് ലക്ഷ്യങ്ങൾ വെവ്വേറെ പരിശോധിച്ച് ഓരോ ഫലവും എഴുതുക: റൗട്ടറിന്റെ സ്വന്തം LAN വിലാസം, അതേ സ്വിച്ചിലുള്ള മറ്റൊരു ഉപകരണം IP പ്രകാരം, ടണൽ വഴി മാത്രം എത്താവുന്ന എന്തെങ്കിലും. ഈ ക്രമത്തിൽ ചെയ്യുക, ഓരോ ഫലവും വ്യത്യസ്ത ലെയർ ഒഴിവാക്കുന്നു. ആദ്യ റൗണ്ടിൽ പേരുകൾക്ക് പകരം വിലാസങ്ങൾ ഉപയോഗിക്കുക, പേരിന്റെ പരാജയം DNS-നെ കണക്റ്റിവിറ്റി ചോദ്യത്തിൽ കലർത്തുന്നു.
ഉത്തരങ്ങളുടെ മാതൃകയാണ് രോഗനിർണയം. പ്രാദേശിക ഉപകരണങ്ങൾ ഉത്തരം നൽകാതെ റൗട്ടർ ഉത്തരം നൽകിയാൽ അത് റൂട്ടിംഗിനെക്കാൾ പ്രാദേശിക സ്വിച്ചിംഗിനെയോ ഫിൽട്ടറിംഗ് സവിശേഷതയെയോ സൂചിപ്പിക്കുന്നു. ടണൽ വശം ഉത്തരം നൽകാതെ പ്രാദേശിക ഉപകരണങ്ങൾ ഉത്തരം നൽകിയാൽ അത് ടണൽ റൂട്ടിനെയോ ദൂരെയുള്ള ഫയർവാളിനെയോ സൂചിപ്പിക്കുന്നു. വിലാസം കൊണ്ട് എല്ലാം ഉത്തരം നൽകുകയും പേരുകൾ പരാജയപ്പെടുകയും ചെയ്താൽ അത് റിസോൾവർ ചോദ്യമാണ്, റൂട്ട് എഡിറ്റ് ചെയ്ത് അത് ശരിയാകില്ല.
| What answers | What it points at |
|---|---|
| Router only | LAN-side filtering or a broken bridge |
| Router and local hosts, not remote | Tunnel route, NAT or remote firewall |
| Addresses yes, names no | DNS handed to clients by the router |
| Nothing at all | Client subnet or router LAN address changed |
പരിശോധനാ ഫലങ്ങൾക്കൊപ്പം പട്ടിക സൂക്ഷിക്കുക. അത് അവ്യക്തമായ പരാതിയെ നിങ്ങൾക്ക് നടപടിയെടുക്കാവുന്ന ഒരു വരിയാക്കി മാറ്റുന്നു.
ഫോർവേഡ് പാത്തിനുള്ളിലെ സുരക്ഷാ ലെയർ
ഉപഭോക്തൃ റൗട്ടറുകളിൽ ഫോർവേഡ് ചെയ്യുന്ന ട്രാഫിക് നിരീക്ഷിക്കുന്ന പരിശോധനാ സവിശേഷത കൂടുതലായി വരുന്നു, അത് LAN-ൽ നിന്ന് ടണലിലേക്ക് പാക്കറ്റുകൾ കൊണ്ടുപോകുന്ന അതേ പാത്തിലാണ് പ്രവർത്തിക്കുന്നത്. ആ പരിശോധനയ്ക്ക് ടണൽ ട്രാഫിക് തരംതിരിക്കാൻ കഴിയാതെ വന്നാൽ, ടണൽ തന്നെ പ്രവർത്തനക്ഷമമായിരിക്കെ റൗട്ടർ ആരോഗ്യകരമായ കണക്ഷൻ റിപ്പോർട്ട് ചെയ്യുമ്പോൾ ഫോർവേഡിംഗ് നിലച്ചേക്കാം. VPN ലോഗിൽ ഇത് കാണുന്നില്ല, കാരണം VPN യഥാർത്ഥത്തിൽ കണക്ട് ചെയ്തു.
രോഗനിർണയം നിയന്ത്രിത പരീക്ഷണമാണ്, സ്ഥിരമായ മാറ്റമല്ല. നിലവിലെ ക്രമീകരണം എഴുതുക, ഒരു പരിശോധനയുടെ ദൈർഘ്യത്തേക്ക് സവിശേഷത ഓഫ് ചെയ്യുക, ടണൽ വീണ്ടും ഉയർത്തുക, വിലാസം കൊണ്ട് ഒരു പ്രാദേശിക ഹോസ്റ്റ് പരിശോധിക്കുക. തിരികെ വരുന്ന ഫോർവേഡിംഗാണ് നിങ്ങൾക്ക് വേണ്ട തെളിവ്, അപ്പോൾ വ്യാപാരം ഊഹത്തിന് പകരം തീരുമാനമാകുന്നു. ഒന്നും മാറിയില്ലെങ്കിൽ ഉടൻ വീണ്ടും ഓൺ ചെയ്ത് വിലാസ കാരണത്തിലേക്ക് പോകുക.
ടണൽ പ്രവർത്തിക്കാൻ പണമടച്ച സുരക്ഷാ സവിശേഷത ഓഫ് ആക്കി വെക്കുന്നത് ബോധപൂർവം ചെയ്ത് എഴുതേണ്ട വ്യാപാരമാണ്. ടണൽ മറ്റൊരു ഉപകരണത്തിലായിരിക്കണോ എന്ന് ചോദിക്കുന്നതും മൂല്യമുള്ളതാണ്, എല്ലാം പരിശോധിക്കേണ്ട റൗട്ടറും എല്ലാം ഫോർവേഡ് ചെയ്യേണ്ട റൗട്ടറും രണ്ട് വ്യത്യസ്ത ജോലികളാണ്.
രണ്ടാമത്തെ കാരണം: LAN പരിധി നീങ്ങി
ഫേംവെയർ അപ്ഡേറ്റുകൾ LAN വിലാസം നിർമ്മാതാവിന്റെ സ്ഥിരസ്ഥിതിയിലേക്ക് പതിവായി പുനഃസ്ഥാപിക്കുന്നു, ചില റൗട്ടറുകളിൽ LAN സ്വകാര്യ പരിധി നിലനിർത്തണോ മുകളിലെ ഉപകരണത്തിൽ നിന്ന് ഒന്ന് പാരമ്പര്യമായി എടുക്കണോ എന്ന് തീരുമാനിക്കുന്ന വ്യക്തമായ മോഡ് സ്വിച്ച് ഉണ്ട്. 192.168.8.x പ്രതീക്ഷിക്കുന്ന ക്ലൈന്റ് 10.64.0.x-ൽ എത്തിയേക്കാം, അപ്പോൾ ടണൽ പൂർണ്ണമായി ആരോഗ്യകരമായിരുന്നാലും ഹോസ്റ്റിലേക്കുള്ള SSH സെഷൻ കാലഹരണപ്പെടുന്നു.
ipconfig /all
ip addr show
ip route get 192.168.8.20റൗട്ടർ പേജ് തുറക്കുന്നതിന് മുമ്പ് ലീസിൽ നിന്ന് പ്രിഫിക്സും ഗേറ്റ്‌വേയും വായിക്കുക. ആദ്യ രണ്ട് കമാൻഡുകൾ ക്ലൈന്റിന് യഥാർത്ഥത്തിൽ ലഭിച്ചത് കാണിക്കുന്നു, മൂന്നാമത്തേത് പ്രാദേശിക വിലാസത്തിന് ക്ലൈന്റ് ഏത് ഇന്റർഫേസ് ഉപയോഗിക്കുമെന്ന് കാണിക്കുന്നു, അങ്ങനെയാണ് ബാക്കിയുള്ള റൂട്ടോ പഴയ സബ്നെറ്റോ വെളിപ്പെടുന്നത്. തുടർന്ന് അത് LAN പേജുമായും റൗട്ടർ ഇരിക്കുന്ന മോഡുമായും താരതമ്യം ചെയ്യുക.
പരിധിക്ക് തിരികെ വരാൻ കഴിയുന്നില്ലെങ്കിൽ അത് പേരിടുന്ന ഓരോ ഒബ്ജക്റ്റും അപ്ഡേറ്റ് ചെയ്യുക: DHCP റിസർവേഷനുകൾ, പഴയ സബ്നെറ്റിലേക്കുള്ള ഏതെങ്കിലും സ്റ്റാറ്റിക് റൂട്ട്, മുൻ പ്രിഫിക്സ് വഹിക്കുന്ന ഓരോ ഫയർവാൾ നിയമവും. ടണലിന്റെ ദൂരെയുള്ള സബ്നെറ്റുമായി കൂട്ടിയിടിക്കുന്ന പരിധിയാണ് മോശം രൂപം, കാരണം പ്രാദേശിക ഉപകരണങ്ങൾ എത്താവുന്നതായി തുടരുമ്പോൾ ദൂരെയുള്ള ലക്ഷ്യങ്ങൾ നിശബ്ദമായി LAN-ലേക്ക് തെറ്റായി റൂട്ട് ചെയ്യപ്പെടുന്നു.
വീണ്ടും കണക്ട് ചെയ്ത് പാക്കറ്റ് ക്രമത്തിൽ വീണ്ടും പരിശോധിക്കുക
രണ്ട് മാറ്റങ്ങളിൽ ഏതെങ്കിലും കഴിഞ്ഞ് ടണൽ വീണ്ടും കണക്ട് ചെയ്ത് പരിശോധനകൾ പാക്കറ്റ് ക്രമത്തിൽ ആവർത്തിക്കുക: റൗട്ടർ, പ്രാദേശിക ഹോസ്റ്റ്, ദൂരെയുള്ള ഹോസ്റ്റ്, പിന്നെ പേരുകൾ, പിന്നെ ആപ്ലിക്കേഷൻ. ആപ്ലിക്കേഷൻ ആദ്യം പരിശോധിക്കുന്നത് ഏത് ലെയർ ഇപ്പോഴും തകർന്നിരിക്കുന്നു എന്ന് മറയ്ക്കുന്നു, കാഷെ ചെയ്ത പേരിനെതിരെ ബ്രൗസറിന്റെ വീണ്ടും ശ്രമം റൂട്ടിംഗ് പരാജയമായി തോന്നിയേക്കാം.
VPN പ്രൊഫൈലിനൊപ്പം ഫേംവെയർ പതിപ്പ്, LAN പ്രിഫിക്സ്, പരിശോധനാ സവിശേഷതയുടെ അവസ്ഥ എന്നിവ എഴുതുക. മൂന്നും അടുത്ത അപ്ഡേറ്റ് മേലെഴുതിയേക്കാവുന്ന ക്രമീകരണമാണ്, രണ്ട് വരി കുറിപ്പുകൾ ഇപ്പോൾ ചെലവിട്ട മണിക്കൂർ ലാഭിക്കുന്നു.