VPN ആപ്പ് ഓണാക്കുമ്പോൾ മാത്രം ഇന്റർനെറ്റ്? നാല് ലെയറുകൾ പരിശോധിക്കുക

ഒരു സൗജന്യ VPN ക്ലയന്റോ ബ്രൗസർ എക്സ്റ്റൻഷനോ ഒരാഴ്ച ഉപയോഗിച്ച ശേഷം അത് ഓഫ് ചെയ്താൽ ഇന്റർനെറ്റ് നിലയ്ക്കുന്നു. Wi-Fi ഐക്കൺ ഇപ്പോഴും കണക്ഷൻ കാണിക്കുന്നു, ഒരേ റൂട്ടറിലെ മറ്റ് ഉപകരണങ്ങൾ കുഴപ്പമില്ലാതെ പ്രവർത്തിക്കുന്നു, ബ്രൗസിംഗ് തിരികെ കൊണ്ടുവരുന്നത് ആപ്പ് വീണ്ടും ഓണാക്കുന്നതോ അൺഇൻസ്റ്റാൾ ചെയ്യുന്നതോ മാത്രമാണ്. ഈ മാതൃക എൻക്രിപ്ഷൻ ഒരു ആശ്രിതത്വം സൃഷ്ടിച്ചതല്ല. ടണൽ കൈവശമില്ലാത്ത ഒരിടത്ത് ആപ്പ് എഴുതി വച്ച ക്രമീകരണമാണ് അത്.

ടണലിന് അധികാരമില്ലാത്ത ക്രമീകരണങ്ങൾ ക്ലയന്റ് മാറ്റുന്നു

Windows-ലോ macOS-ലോ ഉള്ള ഒരു സ്വകാര്യതാ ക്ലയന്റ് സാധാരണയായി ഒരേസമയം മൂന്ന് ഇടങ്ങളിൽ തൊടുന്നു. അത് സിസ്റ്റം HTTP പ്രോക്സി സെറ്റ് ചെയ്യുന്നു, അത് ഇന്റർനെറ്റ് ഓപ്ഷനുകൾ കാണിക്കുന്ന അതേ ഫീൽഡാണ്. പാക്കറ്റുകൾ പിടിച്ചെടുക്കാൻ അത് ഒരു വെർച്വൽ അഡാപ്റ്റർ, പലപ്പോഴും TAP ഡ്രൈവർ, ഇൻസ്റ്റാൾ ചെയ്യുന്നു. അത് റിസോൾവർ ലിസ്റ്റ് മാറ്റിയെഴുതുന്നു, എന്നാൽ ഡിസ്കണക്ട് അമർത്തുമ്പോൾ അപ്രത്യക്ഷമാകുന്നത് ടണൽ മാത്രമാണ്.

ബ്രൗസർ എക്സ്റ്റൻഷൻ കൂടുതൽ ഇടുങ്ങിയ ഒന്നാണ്. അത് സാധാരണയായി സ്വന്തം പ്രൊഫൈലോ ഒരു ബ്രൗസർ പിന്തുടരുന്ന പ്രോക്സിയോ മാറ്റുന്നു. അതുകൊണ്ടാണ് ഒരു ബ്രൗസർ പരാജയപ്പെടുമ്പോൾ കമാൻഡ് ലൈൻ ടൂളുകൾ പ്രവർത്തിക്കുന്നത്, അല്ലെങ്കിൽ നേരെ മറിച്ച്: മറ്റ് ലെയറുകളിൽ തൊടാൻ എക്സ്റ്റൻഷന് ഒരിക്കലും അധികാരമുണ്ടായിരുന്നില്ല. അത് ഏത് ലെയർ തിരുത്തി എന്നതാണ് ഏത് ടൂളുകൾ തകരുമെന്ന് തീരുമാനിക്കുന്നത്.

ഏത് വഴിയായാലും, കാലഹരണപ്പെട്ട ആ തീരുമാനം അത് പിൻവലിക്കാൻ കാരണമില്ലാത്ത സോഫ്റ്റ്വെയർ എടുത്തതാണ്. ടണൽ ആയിരുന്നു ദൃശ്യമായ ഭാഗം, വ്യക്തമായ ഷട്ട്ഡൗൺ പാതയുള്ള ഏക ഭാഗവും അതുതന്നെ. ബാക്കിയെല്ലാം പ്രോസസിനെ അതിജീവിക്കുന്ന ഒരു സ്റ്റോറിലെ ക്രമീകരണമാണ്, അതിനാൽ ആപ്പ് നീക്കം ചെയ്യുക എന്നത് മൂന്നും ഒരുമിച്ച് പിൻവലിക്കുന്ന ഒറ്റ ഘട്ടമാണ്. വീണ്ടും ഇൻസ്റ്റാൾ ചെയ്യുന്നതിന് മുൻപ് ആ സ്റ്റോറുകൾ വായിക്കുന്നതാണ് ലക്ഷണത്തെ രോഗനിർണയമാക്കി മാറ്റുന്നത്.

മൂന്ന് അവശിഷ്ടങ്ങൾ, മൂന്ന് വ്യത്യസ്ത പരാജയങ്ങൾ

ആദ്യത്തെ അവശിഷ്ടം ഒന്നിനെയും ചൂണ്ടാത്ത ഒരു പ്രോക്സിയാണ്: LAN പ്രോക്സി ബോക്സ് ഇപ്പോഴും ടിക്ക് ചെയ്തിരിക്കുന്നു, അല്ലെങ്കിൽ ഒരു കോൺഫിഗറേഷൻ സ്ക്രിപ്റ്റ് URL ഇപ്പോൾ പ്രോസസ് കേൾക്കാത്ത ഒരു localhost പോർട്ടിലേക്ക് ചൂണ്ടുന്നു. ബ്രൗസർ ഓരോ അഭ്യർത്ഥനയും ആ മരിച്ച പോർട്ടിലേക്ക് അയച്ച്, ടൈംഔട്ട് ഒരു മരിച്ച നെറ്റ്വർക്ക് പോലെ തോന്നുന്നതുവരെ കാത്തിരിക്കുന്നു. രണ്ടാമത്തേത് ഇപ്പോഴും ഒരു ഡിഫോൾട്ട് റൂട്ട് കൈവശമുള്ള അഡാപ്റ്ററാണ്, കാരണം ഒരു TAP-Windows ഉപകരണമോ വെണ്ടർ റൂട്ടിംഗ് ഡ്രൈവറോ അൺഇൻസ്റ്റാലിന് ശേഷവും യഥാർത്ഥ ഇന്റർഫേസായി തുടരുന്നു. അതിന് നൽകിയ റൂട്ട് അത് സൂക്ഷിക്കുന്നു, ട്രാഫിക് ഇല്ലാത്ത ഒരു ടണലിലേക്ക് മറയുന്നു. ഒരു അവശിഷ്ടവും സ്വയം പ്രഖ്യാപിക്കുന്നില്ല; രണ്ടും ഒരു തകരാർ പോലെത്തന്നെ കാണപ്പെടുന്നു.

മൂന്നാമത്തേത് DNS ആണ്, അത് മറ്റ് രണ്ടിനെക്കാൾ നേരത്തെ പരാജയപ്പെടുന്നു. ടണലിലൂടെ എത്താവുന്ന സെർവറുകൾ മാത്രമാണ് റിസോൾവർ ലിസ്റ്റിൽ ഉള്ളതെങ്കിൽ, ഒരു പേജ് പോലും അഭ്യർത്ഥിക്കുന്നതിന് മുൻപ് ഓരോ ലുക്കപ്പും ടൈംഔട്ടാകുന്നു, അതിനാൽ മരിച്ച പ്രോക്സിയെക്കാൾ ബ്രൗസർ എത്താനാവാത്ത ഒരു സൈറ്റാണ് റിപ്പോർട്ട് ചെയ്യുന്നത്. നിങ്ങൾക്ക് അതിൽ ഏതാണെങ്കിലും, നെറ്റ്വർക്ക് അർത്ഥത്തിൽ അവയൊന്നും ഒരു തകരാറല്ല. ഓരോന്നും ആരും പിൻവലിക്കാത്ത ഒരു അവശിഷ്ടമാണ്, ഓരോന്നും വേറെയൊരു ഇടത്താണ് നന്നാക്കുന്നത്.

നാല് ലെയറുകളിലൂടെ താഴേക്ക് പോകുക

ആപ്ലിക്കേഷനോട് ഏറ്റവും അടുത്തുനിന്ന് തുടങ്ങി താഴേക്ക് പോകുക, കാരണം ലെയറുകൾ പരാജയപ്പെടുന്നത് ആ ദൃശ്യതാക്രമത്തിലാണ്. ഓരോ പരിശോധനയിലും ഒരു ലെയർ മാത്രം മാറ്റി, ഓരോന്നിനും ശേഷം വീണ്ടും പരിശോധിക്കുക. എല്ലാം ഒരുമിച്ച് റീസെറ്റ് ചെയ്യുന്നത് സാധാരണയായി ബ്രൗസിംഗ് തിരികെ കൊണ്ടുവരുന്നു, പക്ഷേ ഏത് അവശിഷ്ടമാണ് അതിന് കാരണമെന്ന് പറയാൻ അത് നിങ്ങളെ അനുവദിക്കുന്നില്ല, അതിനാൽ അടുത്ത ഇൻസ്റ്റാൾ അതേ കടങ്കഥ വീണ്ടും സൃഷ്ടിക്കുന്നു. ക്രമം പ്രോക്സി, അഡാപ്റ്ററുകൾ, റൂട്ടുകൾ, റിസോൾവറുകൾ എന്നതാണ്.

Windows-ൽ ഓരോ പരിശോധനയും ഓപ്പറേറ്റിംഗ് സിസ്റ്റത്തോടൊപ്പം വരുന്ന ഒരു കമാൻഡ് മാത്രമാണ്, അതിനാൽ ഒന്നും ഇൻസ്റ്റാൾ ചെയ്യേണ്ടതില്ല. അവ ക്രമത്തിൽ പ്രവർത്തിപ്പിച്ച് ഔട്ട്പുട്ട് ഒരുമിച്ച് സൂക്ഷിക്കുക, കാരണം നാല് ഉത്തരങ്ങളും അടുത്തടുത്തായി മാത്രമേ അർത്ഥവത്താകൂ. അവ പ്രോക്സി, അഡാപ്റ്ററുകൾ, IPv4 റൂട്ടുകൾ, റിസോൾവർ ലിസ്റ്റ് എന്ന ക്രമത്തിൽ റിപ്പോർട്ട് ചെയ്യുന്നു:

netsh winhttp show proxy
Get-NetAdapter
route print -4
Get-DnsClientServerAddress

Linux-നും macOS-നും സ്വന്തം കമാൻഡുകൾ വേണം, അവ പരസ്പരം പകരമാകില്ല. Linux-ൽ റൂട്ടുകൾ ip route-ൽ നിന്നും, systemd-resolved അത് കൈവശമുള്ളിടത്ത് റിസോൾവർ resolvectl status-ൽ നിന്നും വരുന്നു, അല്ലാത്തപ്പോൾ cat /etc/resolv.conf-ലേക്ക് പിൻവാങ്ങുന്നു. macOS-ൽ റൂട്ടുകൾ netstat -rn-ൽ നിന്നും, റിസോൾവറുകൾ scutil --dns-ൽ നിന്നും, സിസ്റ്റം പ്രോക്സി scutil --proxy-ൽ നിന്നും വരുന്നു. ip route പ്രവർത്തിപ്പിക്കുന്ന ഒരു macOS ഉപയോക്താവിന് command not found ലഭിക്കും, അവിടെ /etc/resolv.conf ഒരു സൃഷ്ടിത സ്റ്റബ് ആണ്, അധികാരമുള്ള കോൺഫിഗറേഷനല്ല. ലെയർ പരിശോധിക്കുന്നതിന് മുൻപ് പ്ലാറ്റ്ഫോം പരിശോധിക്കുക, അല്ലെങ്കിൽ ആദ്യ കമാൻഡ് തന്നെ കണ്ടെത്തലാകും.

ഓരോ ലെയറിനും ഒരു ചോദ്യം ചോദിക്കുക: ആപ്പ് അടച്ചിരിക്കുമ്പോൾ ഈ മൂല്യം ഇപ്പോഴും നിലവിലുള്ള എന്തെങ്കിലും ചൂണ്ടുന്നുണ്ടോ? മരിച്ച പോർട്ടിലെ പ്രോക്സി, ടണലില്ലാത്ത അഡാപ്റ്റർ, ഡൗൺ ഇന്റർഫേസിലൂടെയുള്ള ഡിഫോൾട്ട് റൂട്ട്, ടണലിനുള്ളിലെ റിസോൾവർ എന്നിവയെല്ലാം ഇല്ല എന്നാണ് ഉത്തരം പറയുന്നത്. ഏതെങ്കിലും ഒരു ഇല്ല എന്നത് ലക്ഷണം വിശദീകരിക്കാൻ മതിയാകും, അതുകൊണ്ടാണ് ഓരോ പരിശോധനയിലും ഒരു മാറ്റം എന്നത് പ്രധാനമാകുന്നത്.

പ്രോക്സി ഒരു ടണലല്ല

ഒരു പ്രോക്സി അഭ്യർത്ഥന സ്വീകരിച്ച്, അത് മറ്റൊരിടത്ത് എടുത്തുവന്ന്, പ്രതികരണം തിരികെ നൽകുന്നു, അതായത് അത് ലക്ഷ്യം അറിയുന്നു, സൈറ്റ് സ്വയം എൻക്രിപ്റ്റ് ചെയ്യാത്തതെല്ലാം കാണുന്നു. അത് മറ്റ് പ്രോട്ടോക്കോളുകൾ വഹിക്കുന്നില്ല. ലക്ഷ്യം ഇതിനകം TLS ഉപയോഗിക്കുന്നില്ലെങ്കിൽ അത് പാത സംരക്ഷിക്കുന്നില്ല. അത് ഇൻസ്റ്റാൾ ചെയ്തതെന്തോ അത് നിങ്ങളുടെ പങ്കാളിത്തമില്ലാതെ അത് മാറ്റാനും കഴിയും.

ആ വ്യത്യാസം ചോദിക്കേണ്ട ചോദ്യത്തെ മാറ്റുന്നു. ഒരു പ്രോക്സി പിന്നിൽ അവശേഷിക്കുമ്പോൾ, ടണൽ ഓണാണോ എന്നതിനുപകരം ഏത് പ്രോഗ്രാമാണ് ഇപ്പോഴും നിങ്ങളുടെ ബ്രൗസറിനെ നയിക്കുന്നതെന്ന് കണ്ടെത്തുക. ടണൽ തികച്ചും ആരോഗ്യകരവും ഈ പരാജയത്തിന് തികച്ചും അപ്രസക്തവുമായിരിക്കാം.

അത്തരം ഒരു ക്ലയന്റ് യഥാർത്ഥത്തിൽ എന്ത് ചെയ്തുവെന്ന് അറിയാൻ, അതിന്റെ ഡാഷ്ബോർഡ് വായിക്കുന്നതിനുപകരം അത് നിരീക്ഷിക്കുക. Process Monitor അത് തൊടുന്ന രജിസ്ട്രി കീകളും ഫയലുകളും രേഖപ്പെടുത്തുന്നു, പാക്കറ്റ് ക്യാപ്ചർ അതിന്റെ ട്രാഫിക് എവിടെ പോയെന്ന് വെളിപ്പെടുത്തുന്നു. രണ്ടും സാധാരണ ടൂളുകളാണ്, ഏത് സ്റ്റാറ്റസ് ലൈറ്റിനെക്കാളും നന്നായി അവശിഷ്ടത്തിന്റെ ചോദ്യത്തിന് രണ്ടും ഉത്തരം നൽകുന്നു. ആപ്പ് ഇപ്പോഴും പ്രവർത്തിക്കണമെന്ന് അവയൊന്നും ആവശ്യപ്പെടുന്നില്ല.

തെളിവല്ല, ഘടകം നീക്കം ചെയ്യുക

ഈ ക്രമീകരണം എഴുതിയതിനെ നീക്കം ചെയ്യുകയാണ് ശാശ്വതമായ പരിഹാരം. ആപ്പ് അൺഇൻസ്റ്റാൾ ചെയ്യുക, അത് ചേർത്ത വെർച്വൽ അഡാപ്റ്റർ ഇല്ലാതാക്കുക, പ്രോക്സിയും റിസോൾവർ ലിസ്റ്റും വ്യക്തമാക്കുക, എന്നിട്ട് റീബൂട്ട് ചെയ്ത് ആപ്പ് അൺഇൻസ്റ്റാൾ ചെയ്ത നിലയിൽ തന്നെ പരിശോധിക്കുക. ആ ഘട്ടത്തിൽ ബ്രൗസിംഗ് പ്രവർത്തിക്കുന്നുണ്ടെങ്കിൽ, ഒരു പരിഹാരവഴിയല്ല, കാരണം തന്നെയാണ് നിങ്ങൾ കണ്ടെത്തിയത്. ഏത് ലെയറാണ് കാലഹരണപ്പെട്ടതെന്ന് ഒരു കുറിപ്പിടുക, കാരണം അതേ വെണ്ടർ അതേ തെറ്റ് രണ്ടുതവണ അയയ്ക്കാൻ മടിക്കാറില്ല.

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

വീണ്ടും ഇൻസ്റ്റാൾ ചെയ്യുന്നത് പ്രോക്സി റീസെറ്റ് ചെയ്യും, പക്ഷേ കാലഹരണപ്പെട്ട ഒരു അഡാപ്റ്ററിനെ അല്ല, ലിസ്റ്റിൽ രണ്ട് റിസോൾവറുകൾ അവശേഷിപ്പിക്കാനും ഇടയുണ്ട്. ആ അസമതയാണ് എല്ലാം റീസെറ്റ് ചെയ്യുന്ന ബട്ടണിനെക്കാൾ അൺഇൻസ്റ്റാൾ-പിന്നെ-പരിശോധന മികച്ചതാകുന്നതിന്റെ കാരണം. കണക്ഷൻ വീഴുന്ന അടുത്ത തവണ താരതമ്യം ചെയ്യാൻ ഒരു അടിസ്ഥാനരേഖയും അത് നിങ്ങൾക്ക് നൽകുന്നു.