VPN കണക്ട് ചെയ്തു, പക്ഷേ ഇന്റർനെറ്റ് ഇല്ലേ? നാല് പാളികൾ പരിശോധിക്കുക

ക്ലയന്റ് കണക്ട് ചെയ്തു എന്നു പറയുന്നു, ബ്രൗസർ കറങ്ങുന്നു, ഓരോ സൈറ്റും ടൈംഔട്ടിൽ അവസാനിക്കുന്നു. ഈ സംയോജനം സാധാരണമാണ്, വൈരുദ്ധ്യമല്ല: കണക്ട് എന്നാൽ ടണൽ ചർച്ച നടത്തി, അത്രമാത്രം. പേര് വിശകലനം, റൂട്ടിംഗ്, സെർവറിന്റെ സ്വന്തം എക്സിറ്റ് എന്നിവ ഓരോന്നും അതതു രീതിയിൽ പരാജയപ്പെടുന്നു, ഓരോന്നിനും വ്യത്യസ്ത ഉടമയുണ്ട്. പാളികൾ ക്രമത്തിൽ പരിശോധിച്ച് ആദ്യം പരാജയപ്പെടുന്നതിൽ നിർത്തുക.

നിങ്ങൾ വന്ന നെറ്റ്വർക്കിൽ നിന്നു തുടങ്ങുക

ക്ലയന്റിന്റെ സ്വന്തം ഡിസ്കണക്ട് നിയന്ത്രണം ഉപയോഗിച്ച് ടണൽ താഴെയിറക്കി, നയം അനുവദിക്കുകയാണെങ്കിൽ ബന്ധമില്ലാത്ത രണ്ട് HTTPS സൈറ്റുകൾ പരീക്ഷിക്കുക. ആ പരിശോധനയുടെ കാലത്ത് സൂക്ഷ്മമായ ജോലി അടച്ചിടുക. സാധാരണ ആക്സസും പരാജയപ്പെട്ടാൽ VPN ആദ്യ സംശയിതനല്ല.

ടണലിൽ തൊടുന്നതിന് മുൻപ് Wi-Fi ലിങ്ക്, റൗട്ടർ, സൈൻ-ഇൻ ആവശ്യപ്പെടുന്ന ഏതു പോർട്ടൽ പേജും നോക്കുക. കിൽ സ്വിച്ച് രൂപകൽപ്പന പ്രകാരം ഡിസ്കണക്ട് ആയിരിക്കുമ്പോൾ ട്രാഫിക് തടയാം, അതിനാൽ നെറ്റ്വർക്ക് മരിച്ചു എന്ന് തീരുമാനിക്കുന്നതിനു പകരം അതിന്റെ രേഖപ്പെടുത്തിയ പരിശോധനാ നടപടിക്രമം പിന്തുടരുക. മറ്റൊരു വിശ്വസ്ത നെറ്റ്വർക്ക് ഉപയോഗപ്രദമായ താരതമ്യമാണ്, പുതിയ VPN എക്സിറ്റ് കാലഹരണപ്പെട്ട ഹോട്ടൽ സൈൻ-ഇൻ പൂർത്തിയാക്കില്ല. തുറന്ന നെറ്റ്വർക്ക് പ്രവർത്തിച്ച് ടണൽ പ്രവർത്തിക്കാത്തുവെങ്കിൽ നെറ്റ്വർക്ക് നിർദോഷമാണ്, അടുത്ത പാളി നിങ്ങളുടേതാണ്.

പരാജയം പേര് വിശകലനമാണോ എന്ന് തീരുമാനിക്കുക

പിശകിന്റെ വാചകം എഴുതിവയ്ക്കുക, കാരണം വിശകലന പരാജയം, ടൈംഔട്ട്, സർട്ടിഫിക്കറ്റ് മുന്നറിയിപ്പ് എന്നിവ ഓരോന്നും വേറെയിടത്തേക്ക് ചൂണ്ടുന്നു. നേരത്തെ പിടിക്കേണ്ട മാതൃക: ഒരിക്കലും സന്ദർശിക്കാത്ത ഹോസ്റ്റ്നെയിം പരാജയപ്പെടുന്നു, തുറന്ന സെഷനുള്ള ആപ്പ് തുടരുന്നു. ഈ മാതൃക പുതിയ അന്വേഷണങ്ങളെക്കുറിച്ചാണ്, ടണൽ പാക്കറ്റ് കൊണ്ടുപോകുന്നുണ്ടോ എന്നതിനെക്കുറിച്ചല്ല. ഒരു അന്വേഷണം റിസോൾവർ എന്ത് തിരികെ നൽകുന്നു എന്ന് കാണിക്കുന്നു, അത് പ്രവർത്തിപ്പിക്കാൻ ഒരു സെക്കൻഡ് മതി. രണ്ടാമത്തെ പേരും പരീക്ഷിക്കുക, ഒരു കാഷെ ചെയ്ത ഉത്തരം അല്ലെങ്കിൽ ഒരു കേടായ റെക്കോർഡ് രോഗനിർണയം തീരുമാനിക്കാതിരിക്കാൻ.

nslookup example.com

HTTPS വിലാസ പട്ടിയിലെ അനിയന്ത്രിത IP DNS പരിശോധനയല്ല, കാരണം സർട്ടിഫിക്കറ്റും വെർച്വൽ ഹോസ്റ്റും സാധാരണയായി പേരിനെ ആശ്രയിച്ചിരിക്കുന്നു. ആന്തരിക പേരുകൾക്ക് പൊതു പകരംവയ്ക്കലിനു പകരം സംഘടനയുടെ റിസോൾവർ ആവശ്യമായേക്കാം, സ്വന്തം സുരക്ഷിത റിസോൾവറുള്ള ബ്രൗസർ ഓപ്പറേറ്റിംഗ് സിസ്റ്റത്തിന്റെ അന്വേഷണത്തിൽ നിന്ന് വ്യത്യസ്തമായി ഉത്തരം നൽകിയേക്കാം. രണ്ടും വിയോജിക്കുന്നിടത്ത് ഉപയോക്താവ് അനുഭവിക്കുന്നത് ബ്രൗസറിന്റെ റിസോൾവറാണ്, ആ വ്യത്യാസം ടിക്കറ്റിന്റേതാണ്.

പൂർണ ടണലോ കമ്പനി സബ്നെറ്റുകൾ മാത്രമോ

ചില പ്രൊഫൈലുകൾ കമ്പനിയുടെ കുറച്ച് സബ്നെറ്റുകളിൽ എത്താൻ മാത്രമുള്ളവയാണ്; മറ്റുള്ളവ എല്ലാം കൊണ്ടുപോകാൻ നിർമ്മിച്ചവയും പിന്നിൽ പ്രവർത്തിക്കുന്ന എക്സിറ്റ് ആവശ്യമുള്ളവയുമാണ്. സൂചകം ഓരോ ആപ്പിനെയും ഓരോ വിലാസ കുടുംബത്തെയും ഉൾക്കൊള്ളുന്നു എന്ന് കരുതുന്നതിന് മുൻപ് രേഖപ്പെടുത്തിയ ഉദ്ദേശ്യം വായിക്കുക. സ്വകാര്യ നെറ്റ്വർക്ക് പ്രൊഫൈൽ രൂപകൽപ്പന പ്രകാരം കൃത്യമായി പ്രവർത്തിച്ചേക്കാം, അത് ഉപയോഗിക്കേണ്ടതില്ലാത്ത ബ്രൗസർ ഇപ്പോഴും പരാജയപ്പെടുമ്പോൾ. റൂട്ട് പട്ടിക മാറ്റാതെ വായിക്കുക, IPv6 ഉൾപ്പെടുത്തുക, കാരണം പ്രവർത്തിക്കുന്ന IPv4 പാത മറ്റേ കുടുംബത്തെക്കുറിച്ച് ഒന്നും പറയുന്നില്ല.

കൂടുതൽ നിർദ്ദിഷ്ട റൂട്ട് ഡിഫോൾട്ട് റൂട്ട് നിലനിൽക്കുമ്പോൾ വിജയിച്ചേക്കാം, അതിനാൽ പട്ടിക അനുമാനിക്കാതെ വായിക്കണം. മത്സരിക്കുന്ന വെർച്വൽ അഡാപ്റ്ററുകൾക്ക് നിങ്ങൾ മറ്റെവിടെയോ പ്രതീക്ഷിച്ച ട്രാഫിക്കും ഉണ്ടായേക്കാം, പ്രത്യേകിച്ച് രണ്ടാമത്തെ VPN ക്ലയന്റ് ഇൻസ്റ്റാൾ ചെയ്ത് മറന്നതിന് ശേഷം. പരീക്ഷണമായി ഡിഫോൾട്ട് റൂട്ട് ഇല്ലാതാക്കരുത്; അത് രോഗനിർണയത്തെ രണ്ടാമത്തെ തടസ്സമാക്കുന്നു.

പ്രവർത്തിക്കുന്നവയ്ക്കിടയിൽ ഒരു സൈറ്റ് മാത്രം പരാജയപ്പെടുന്നത് ആ സൈറ്റിന്റെ പ്രശ്നമാണ്, ടണൽ ട്രാഫിക് കൊണ്ടുപോകുന്നു എന്നതിന്റെ തെളിവുമാണ്. വലിയ കൈമാറ്റങ്ങളിൽ മാത്രം കാണുന്ന നിർത്തലുകൾ എത്തിച്ചേരാനുള്ള കഴിവിനെയല്ല, പാക്കറ്റ് വലുപ്പത്തെയാണ് ചൂണ്ടുന്നത്.

സെർവർ ഒന്നും ഫോർവേഡ് ചെയ്യാത്തപ്പോൾ

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

ആ മൂന്നും സെർവർ വശത്തെ കാരണങ്ങളിൽ ഭൂരിഭാഗവും ഉൾക്കൊള്ളുന്നു, ഉത്തരം നൽകേണ്ടത് ഓപ്പറേറ്ററാണ്. OpenVPN കണക്റ്റിവിറ്റി പ്രശ്നപരിഹാര പേജ് സെർവർ വശത്തുനിന്ന് അതേ ചോദ്യങ്ങൾ നടത്തുന്നു, അതിനാൽ അത് ടിക്കറ്റിനൊപ്പം കൈമാറുക. പച്ച സൂചകത്തിന്റെ സ്ക്രീൻഷോട്ട് അവയിലൊന്നിനും ഉത്തരം നൽകുന്നില്ല.

സൈൻ-ഇന്നിന് ശേഷമുള്ള ക്ലയന്റ് ലോഗിൽ റൂട്ടുകൾ, DNS ക്രമീകരണങ്ങൾ, വെർച്വൽ അഡാപ്റ്റർ എന്നിവ പ്രയോഗിക്കുന്നതിലെ പരാജയങ്ങൾ നോക്കുക. ആ ഘട്ടത്തിലെ പിശകുകൾ സെർവറിനെയല്ല, ഉപകരണത്തെയാണ് ചൂണ്ടുന്നത്. ലോഗിൽ ഒരിക്കലും പ്രത്യക്ഷപ്പെടാത്ത പിശകും അത്രതന്നെ വിവരദായകമാണ്, കാരണം അത് സംശയത്തെ മറുവശത്തേക്ക് മാറ്റുന്നു.

ഒരു സമയത്ത് ഒരു പാളി പരിശോധിക്കുക

എന്തെങ്കിലും മാറ്റിയ ശേഷം വീണ്ടും കണക്ട് ചെയ്ത് പരാജയപ്പെട്ട അതേ ആപ്പ് ആവർത്തിക്കുക. ഒരു പേജ് ലോഡ് ചെയ്യുന്നത് പ്രൊഫൈൽ നിർമ്മിച്ച വിഭവങ്ങളിലേക്കുള്ള ആവർത്തിക്കാവുന്ന പാതയെക്കാൾ കുറഞ്ഞ തെളിവാണ്. രണ്ട് കമാൻഡുകൾ വിശകലനത്തെ എത്തിച്ചേരാനുള്ള കഴിവിൽ നിന്ന് വേർതിരിക്കുന്നു, രണ്ടാമത്തേത് ഹോസ്റ്റിനെ ആശ്രയിച്ചിരിക്കുന്നു. curl വരി എവിടെയും പ്രവർത്തിപ്പിക്കുക, പിന്നെ നിങ്ങളുടെ മുൻപിലുള്ള ഹോസ്റ്റിന് യോജിക്കുന്ന റൂട്ട് കമാൻഡ് പ്രവർത്തിപ്പിക്കുക.

curl -sS -o /dev/null -w "%{http_code}" --max-time 5 https://example.com
route print -4          # Windows
ip -4 route show        # Linux
netstat -rn | head      # macOS

സംഖ്യാ അഭ്യർത്ഥന പ്രവർത്തിച്ച് പേര് പ്രവർത്തിക്കാത്തുവെങ്കിൽ DNS-ൽ തുടരുക. രണ്ടും പ്രവർത്തിക്കാത്തുവെങ്കിൽ റൂട്ട് പട്ടിക ടണലിന്റെ പ്രതീക്ഷിത ഡിഫോൾട്ടുമായി താരതമ്യം ചെയ്യുക, നിങ്ങൾ യഥാർത്ഥത്തിൽ പരിശോധിക്കുന്ന കുടുംബം പരിശോധിക്കുക. റൂട്ട് ശരിയാണെങ്കിലും അഭ്യർത്ഥന ഇപ്പോഴും എക്സിറ്റിൽ മരിക്കുന്നുവെങ്കിൽ ബാക്കി ചോദ്യം ഓപ്പറേറ്ററുടേതാണ്, നിങ്ങൾ സൂക്ഷിച്ച തെളിവുകളാണ് ടിക്കറ്റ്.