VPN കണക്ട് ചെയ്തിരിക്കുമ്പോൾ ലോക്കൽ നെറ്റ്വർക്കിൽ എത്താനാകുന്നില്ലേ? നാല് പരിശോധനകൾ

ടണൽ ഉയരുന്നു, ഇൻട്രാനെറ്റ് കാണാം, പക്ഷേ പ്രിന്റർ മറുപടി നിർത്തുന്നു. LAN-ൽ ഒന്നും കേടായിട്ടില്ല; ഇനി ലോക്കൽ അല്ലാത്ത വിലാസങ്ങൾക്ക് ഏത് വഴി ഉപയോഗിക്കണം എന്ന് ക്ലയന്റ് മാറ്റി. താഴെയുള്ള നാല് പരിശോധനകൾ ക്രമത്തിൽ ചെയ്യുക, ഒന്ന് വ്യക്തമായ പൊരുത്തക്കേട് കാണിക്കുമ്പോൾ നിർത്തുക; ഒരേ ലക്ഷണത്തിന് നാല് സാധാരണ കാരണങ്ങളുണ്ട്, അവയിൽ ഒന്ന് മാത്രമാണ് VPN ക്രമീകരണം മാറ്റി പരിഹരിക്കുന്നത്.

ആദ്യം, ക്ലയന്റ് ഇൻസ്റ്റാൾ ചെയ്ത റൂട്ട് ടേബിൾ നോക്കുക

VPN കണക്ട് ചെയ്തിരിക്കുമ്പോൾ ക്ലയന്റിന്റെ റൂട്ട് ടേബിൾ തുറക്കുക. Linux-ൽ ip route, Windows-ൽ route print അല്ലെങ്കിൽ Get-NetRoute, macOS-ൽ netstat -rn ഉപയോഗിക്കുക. ടണലിലൂടെയുള്ള ഡിഫോൾട്ട് റൂട്ടും ഫിസിക്കൽ ഡിഫോൾട്ടിന് സംഭവിച്ചതും നിങ്ങൾ തിരയുകയാണ്.

ഫുൾ ടണൽ ക്ലയന്റ് 0.0.0.0/0 മാറ്റിസ്ഥാപിക്കുന്നതിന് പകരം 0.0.0.0/1, 128.0.0.0/1 എന്നീ രണ്ട് പകുതി ഡിഫോൾട്ട് റൂട്ടുകൾ ചേർക്കാറുണ്ട്. യഥാർത്ഥ ഡിഫോൾട്ട് കാണാമെങ്കിലും എല്ലാ ലുക്കപ്പുകളിലും തോൽക്കുന്നു, അതിനാൽ ടേബിൾ കേടുകൂടാത്തതായി തോന്നാം, പക്ഷേ സബ്നെറ്റിന് പുറത്തുള്ള എല്ലാ ട്രാഫിക്കും നീങ്ങുന്നു. VPN ക്ലയന്റ് സ്പ്ലിറ്റ് ടണൽ ഓപ്ഷൻ നൽകുകയും നയം അനുവദിക്കുകയും ചെയ്താൽ അതാണ് ഏറ്റവും വൃത്തിയായ പരിഹാരം.

ടണൽ ഡിഫോൾട്ടായി തുടരണമെങ്കിൽ പകരം ലോക്കൽ സബ്നെറ്റ് പിൻ ചെയ്യുക. Linux-ൽ റൂട്ട് ഫിസിക്കൽ ഇന്റർഫേസും ഗേറ്റ്വേയും പേരിടുന്നു; Windows-ൽ -p ചേർത്ത് അത് സ്ഥിരമാക്കി ഇന്റർഫേസ് നമ്പർ ഊഹിക്കാതെ route print-ൽ നിന്ന് വായിക്കുക:

sudo ip route add 192.168.1.0/24 via 192.168.1.1 dev wlan0
route add -p 192.168.1.0 MASK 255.255.255.0 192.168.1.1 METRIC 1 IF 12

പിൻ ചെയ്ത റൂട്ട് അത് പേരിടുന്ന വിലാസം മാറാത്തിടത്തോളം മാത്രമേ നിലനിൽക്കൂ. ഓരോ കണക്ഷനിലും Wi-Fi അഡാപ്റ്ററിന് പുതിയ നമ്പർ ലഭിക്കുന്ന ലാപ്ടോപ്പിൽ നിയമം വീണ്ടും ലംഘിക്കപ്പെടും, അതിനാൽ പരിഹാരം പരാജയപ്പെട്ടു എന്ന് തീരുമാനിക്കുന്നതിന് മുൻപ് ഇന്റർഫേസ് വിലാസം പരിശോധിക്കുക.

രണ്ടാമത്, ആ വിലാസം തുടക്കത്തിലേ ലോക്കൽ ആയിരുന്നോ എന്ന് ഉറപ്പാക്കുക

ലക്ഷ്യസ്ഥാനം കണക്റ്റ് ചെയ്ത സബ്നെറ്റിനുള്ളിലാണെങ്കിൽ ടണലിന്റെ ഡിഫോൾട്ട് ഒരിക്കലും ബാധകമല്ല, VPN കാരണമല്ല. 192.168.1.0/24 ഉള്ള ക്ലയന്റിൽ 192.168.1.40-ലെ പ്രിന്റർ കണക്റ്റഡ് റൂട്ട് ഉപയോഗിക്കുന്നു; ആ വിലാസം പരാജയപ്പെട്ടാൽ VPN അല്ല, ഉപകരണം, സ്വിച്ച്, ക്ലയന്റിന്റെ ഫയർവാൾ എന്നിവ നോക്കുക.

ആളുകളെ കബളിപ്പിക്കുന്ന സന്ദർഭം ലോക്കൽ സെർവറിന് പബ്ലിക് വിലാസം നൽകുന്നതാണ്. LAN-നുള്ളിൽ നിന്ന് റൗട്ടറിന്റെ WAN വിലാസത്തിൽ എത്തി തിരികെ വരാൻ ഹെയർപിൻ NAT ആവശ്യമാണ്, പല റൗട്ടറുകളും പോർട്ട് ഫോർവേഡിംഗിന് അത് നടപ്പാക്കുന്നില്ല. സ്വകാര്യ വിലാസം പബ്ലിക് വിലാസത്തിനൊപ്പം പരീക്ഷിക്കുക. സ്വകാര്യ വിലാസം പ്രവർത്തിക്കുകയും പബ്ലിക് പ്രവർത്തിക്കാതിരിക്കുകയും ചെയ്താൽ, മുൻപേ ഉണ്ടായിരുന്ന NAT പരിമിതി VPN വെളിപ്പെടുത്തിയത്രേ.

ഹോസ്റ്റ്നെയിം ഇത് കൂടുതൽ വഷളാക്കുന്നു. ലോക്കൽ പേര് ഇപ്പോൾ പബ്ലിക് വിലാസത്തിലേക്ക് റിസോൾവ് ചെയ്യുന്നുവെങ്കിൽ, തിരികെ വരാനാകാത്ത വഴി ക്ലയന്റ് പരീക്ഷിച്ചുകൊണ്ടിരിക്കും. പരിശോധനയ്ക്ക് സ്വകാര്യ വിലാസം ഉപയോഗിക്കുക, പിന്നീട് മറ്റൊരു പോർട്ട് ഫോർവേഡിംഗ് ചേർക്കുന്നതിന് പകരം പേര് ശരിയാക്കുക.

മൂന്നാമത്, ഇപ്പോൾ പേരുകൾക്ക് ഉത്തരം നൽകുന്നത് ആരെന്ന് നോക്കുക

കോർപ്പറേറ്റ് റെസോൾവറിന് ഇന്ട്രാനെറ്റ് അറിയാം, പക്ഷേ NAS ഹോസ്റ്റ്നെയിം, പ്രിന്ററിന്റെ Bonjour പേര്, റൗട്ടറിന്റെ ലോക്കൽ അലിയാസ് എന്നിവയെക്കുറിച്ച് സാധാരണയായി ഒന്നും അറിയില്ല. VPN അതിന്റെ DNS സെർവറുകൾ തള്ളുമ്പോൾ, വിലാസങ്ങൾ ഇപ്പോഴും എത്താവുന്നതാണെങ്കിലും ആ പേരുകൾ റിസോൾവ് ചെയ്യുന്നത് നിലയ്ക്കും. പേര് നേരിട്ട് ചോദിച്ച്, ഉപകരണത്തിന് ഉണ്ടെന്ന് നിങ്ങൾക്ക് അറിയാവുന്ന വിലാസവുമായി ഉത്തരം താരതമ്യം ചെയ്യുക.

Linux-ൽ resolvectl query nas.local ഏത് റെസോൾവർ ഉത്തരം നൽകി എന്ന് കാണിക്കും. Windows-ൽ nslookup nas.local സെർവറിന്റെ പേര് നൽകും, ipconfig /all റെസോൾവറുകളുടെ ക്രമം കാണിക്കും. ലോക്കൽ സഫിക്സ് ഇപ്പോൾ കോർപ്പറേറ്റ് റെസോൾവർ കൈകാര്യം ചെയ്യുന്നുവെങ്കിൽ, ആ സഫിക്സ് വീണ്ടും ലോക്കൽ റെസോൾവറിലേക്ക് തിരിച്ചുവിടുക അല്ലെങ്കിൽ ഉപകരണത്തിന് IP വിലാസം ഉപയോഗിക്കുക.

കണ്ടെത്തൽ വേറെ ഒരു പാളിയാണ്. mDNS-ഉം ബ്രോഡ്കാസ്റ്റും റൂട്ട് ചെയ്ത ടണലിനെ കടക്കുന്നില്ല, അതിനാൽ ഉപകരണം വിലാസത്തിൽ എത്താവുന്നതായിരിക്കാം, പേര് അദൃശ്യമായിരിക്കും. റിഫ്ലക്ടറോ ലോക്കൽ DNS എൻട്രിയോ അത് പരിഹരിക്കും; ഒരു റൂട്ട് പരിഹരിക്കില്ല.

നാലാമത്, മറ്റ് മെഷീനും VPN-ൽ ആണോ എന്ന് പരിശോധിക്കുക

നിങ്ങൾക്ക് എത്തേണ്ട മെഷീനും VPN ക്ലയന്റ് ഓടിക്കുന്നുവെങ്കിൽ, നിങ്ങളുടെ സെഷൻ എത്തിയിട്ടും അതിന്റെ മറുപടി മറ്റേ ടണലിലൂടെ പോയേക്കാം. അങ്ങനെ ബന്ധം സ്ഥാപിച്ച് പിന്നീട് കുടുങ്ങുന്നു, അല്ലെങ്കിൽ RDP-യും SSH-ഉം ശ്രമം നിങ്ങളുടെ ഭാഗത്ത് പിശകില്ലാതെ സമയപരിധി കഴിയുന്നു. നിങ്ങളുടെ ക്ലയന്റിനെ കുറ്റപ്പെടുത്തുന്നതിന് മുൻപ് മറ്റേ ഹോസ്റ്റിന്റെ റൂട്ട് ടേബിളും അതിന്റെ ഡിഫോൾട്ട് വഴിയും പരിശോധിക്കുക.

സേവനം കേൾക്കുന്ന വിലാസവും പരിശോധിക്കുക. ടണൽ വിലാസത്തിൽ മാത്രം ബന്ധിച്ച ലിസണർ VPN-ൽ നിന്നുള്ള ബന്ധങ്ങൾ സ്വീകരിക്കുകയും LAN-ൽ നിന്നുള്ളവ നിരസിക്കുകയും ചെയ്യും, റൂട്ടിംഗ് തികഞ്ഞതായാലും. അത് സേവനത്തിന്റെ ക്രമീകരണമാണ്, നെറ്റ്വർക്ക് പാതയല്ല, VPN വിലാസത്തിലേക്ക് പൂട്ടിയ മാനേജ്മെന്റ് ഇന്റർഫേസുകളിൽ ഇത് സാധാരണമാണ്.

ടണലിനെ ആശ്രയിക്കാത്ത ഒരു മാനേജ്മെന്റ് പാത സൂക്ഷിക്കുക: നിങ്ങളുടെ സ്രോതസ്സ് നെറ്റ്വർക്ക് പേരിടുന്ന സ്റ്റാറ്റിക് റൂട്ട്, LAN-ൽ ഘടിപ്പിച്ച മറ്റൊരു ഇന്റർഫേസ്, അല്ലെങ്കിൽ ടണൽ പൂർണമായി ഒഴിവാക്കുന്ന കൺസോൾ. സെഷൻ വീണതിന് ശേഷം ആ പാത രൂപകൽപ്പന ചെയ്യുന്നത് അടുത്ത കണക്ഷന് മുൻപ് ചേർക്കുന്നതിനേക്കാൾ ഏറെ ബുദ്ധിമുട്ടാണ്.

പരാജയപ്പെട്ട പരിശോധനയ്ക്ക് യോജിക്കുന്ന പരിഹാരം പ്രയോഗിക്കുക

റൂട്ട് ടേബിൾ പകുതി ഡിഫോൾട്ട് പിടിച്ചെടുക്കൽ കാണിച്ചുവെങ്കിൽ, നയം അനുവദിക്കുമ്പോൾ സ്പ്ലിറ്റ് ടണലും അല്ലാത്തപ്പോൾ പിൻ ചെയ്ത ലോക്കൽ റൂട്ടും തിരഞ്ഞെടുക്കുക. വിലാസം പബ്ലിക് ആണെന്ന് തെളിഞ്ഞാൽ, പരിശോധനയും പേരും സ്വകാര്യ വിലാസത്തിലേക്ക് മാറ്റുക. റെസോൾവർ കൈ മാറിയെങ്കിൽ ലോക്കൽ സഫിക്സിൽ ഒതുക്കുക അല്ലെങ്കിൽ വിലാസം ഉപയോഗിക്കുക. മറ്റേ ഹോസ്റ്റ് ടണലിലാണെങ്കിൽ അതിന്റെ തിരിച്ചുവരവ് പാതയോ ലിസണർ ബൈൻഡിംഗോ ശരിയാക്കുക.

ഒരു കാര്യം മാറ്റി, അതേ പരിശോധന ആവർത്തിക്കുക. തെറ്റായ സബ്നെറ്റിന് ചേർത്ത റൂട്ട്, അക്ഷരത്തെറ്റുള്ള റെസോൾവർ സഫിക്സ്, പുതിയ നമ്പർ ലഭിക്കുന്ന ഇന്റർഫേസിലെ പിൻ ചെയ്ത റൂട്ട് എന്നിവയെല്ലാം യഥാർത്ഥ തകരാറിനെപ്പോലെ തോന്നും. പരിഹാരത്തെ യാദൃച്ഛികതയിൽ നിന്ന് വേർതിരിക്കുന്നത് ആവർത്തനമാണ്.

VPN കണക്റ്റ് ചെയ്തിരിക്കുമ്പോൾ പ്രവർത്തിച്ച റൂട്ട്, വിലാസം, റെസോൾവർ എന്നിവ എഴുതിവയ്ക്കുക. അടുത്ത റീകണക്ട് അവയിൽ കുറഞ്ഞത് ഒന്നെങ്കിലും മാറ്റും, ആ കുറിപ്പ് അടുത്ത തകരാറിനെ പുതിയ അന്വേഷണത്തിന് പകരം ചെറിയ താരതമ്യമാക്കി മാറ്റും.