OpenVPN പ്രൊഫൈൽ വീട്ടിൽ പ്രവർത്തിക്കുന്നു എന്നാൽ ഹോട്ടലിൽ പരാജയപ്പെടുന്നത് എന്തുകൊണ്ട്

ഓഫീസിലെ Wi-Fi-ഉം ഒരു ഹോട്ടൽ മുറിയും ഒരേ ലാപ്ടോപ്പിന് തികച്ചും വ്യത്യസ്തമായ രണ്ട് നെറ്റ്വർക്കുകൾ നൽകാം, ഇവയ്ക്കിടയിലുള്ള പ്രൊഫൈലിന് അതിനെക്കുറിച്ച് ഒന്നും അറിയില്ല. വീട്ടിൽ പ്രവർത്തിക്കുന്നത് അയവുള്ള അപ്ലിങ്ക്, പ്രവർത്തിക്കുന്ന നാമ വിശകലനം, ടണൽ കൊണ്ടുപോകുന്ന ഒന്നുമായും കൂട്ടിയിടിക്കാത്ത പ്രാദേശിക സബ്നെറ്റ് എന്നിവ അനുമാനിക്കുന്നു. ഈ അനുമാനങ്ങളിൽ ഓരോന്നും വെവ്വേറെ പരാജയപ്പെടാം.

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

നാല് നെറ്റ്വർക്ക് വസ്തുതകൾ സ്ഥലങ്ങൾക്കിടയിൽ മാറുന്നു

ആദ്യ വസ്തുത പ്രാദേശിക നെറ്റ്വർക്ക് നിങ്ങളെ പുറത്തുവിടുന്നുണ്ടോ എന്നതാണ്. ഒരു ക്യാപ്റ്റീവ് പോർട്ടൽ ഉപകരണത്തെ ലോഗിൻ പേജിലേക്ക് കയറ്റി ആ പേജ് പൂർത്തിയാകുന്നതുവരെ ബാക്കിയെല്ലാം തടയുന്നു, അതായത് പ്രൊഫൈൽ എത്ര ശരിയായാലും ടണൽ തുടങ്ങാനാവില്ല.

രണ്ടാമത്തേത് നാമ വിശകലനമാണ്. DNS തടഞ്ഞെടുക്കുന്ന പോർട്ടൽ ഓരോ ചോദ്യത്തിനും സ്വന്തം വിലാസം കൊണ്ട് ഉത്തരം നൽകുന്നു, അതിനാൽ VPN ഹോസ്റ്റ്നെയിം പോർട്ടലിലേക്ക് വിശകലനം ചെയ്യപ്പെടുകയും ക്ലയന്റ് ഒരു വെബ് പേജിലേക്ക് ടണൽ നിർമ്മിക്കാൻ ശ്രമിക്കുകയും ചെയ്യുന്നു.

മൂന്നാമത്തേത് ട്രാൻസ്പോർട്ട് ഫിൽട്ടറിംഗ് ആണ്. ബ്രൗസിംഗ് മാത്രം അനുവദിക്കാൻ ആഗ്രഹിക്കുന്ന നെറ്റ്വർക്കുകൾ TCP 443 ഏത് ലക്ഷ്യസ്ഥാനത്തേക്കും കടത്തിവിടുകയും UDP ഉൾപ്പെടെ ബാക്കിയെല്ലാം ഉപേക്ഷിക്കുകയും ചെയ്യുന്നു.

നാലാമത്തേത് വിലാസനിർണ്ണയമാണ്. പ്രാദേശിക സബ്നെറ്റ് ടണലിനു പിന്നിലെ നെറ്റ്വർക്കുമായി ഓവർലാപ്പ് ചെയ്തേക്കാം, അല്ലെങ്കിൽ അപ്ലിങ്ക് ഉപയോഗപ്രദമായ IPv4 പാത ഒന്നും നൽകിയേക്കില്ല.

നാമ വിശകലനവും ക്യാപ്റ്റീവ് പോർട്ടലും

പ്രൊഫൈലിലെ ഹോസ്റ്റ്നെയിം സെർവറിന്റെ സംഖ്യാ വിലാസം കൊണ്ട് മാറ്റി വീണ്ടും ശ്രമിക്കുക. IP ബന്ധിപ്പിക്കുകയും പേര് ബന്ധിപ്പിക്കാതിരിക്കുകയും ചെയ്താൽ കുറ്റം നാമ വിശകലനത്തിന്റേതാണ്, പ്രൊഫൈൽ തന്നെ കുഴപ്പമില്ല.

VPN തൊടുന്നതിനു മുൻപ് ഒരു ബ്രൗസർ തുറന്ന് സാധാരണ HTTP പേജ് ശ്രമിക്കുക. ലോഗിൻ പേജിലേക്കുള്ള റീഡയറക്ട് എന്നാൽ പോർട്ടൽ ഇനിയും ബാക്കിയുണ്ട്; അത് പൂർത്തിയാക്കി വീണ്ടും ബന്ധിപ്പിക്കുക. പല ഹോട്ടലുകളും കുറച്ച് മണിക്കൂറുകൾക്ക് ശേഷം സെഷൻ അവസാനിപ്പിക്കാറുണ്ട്, അത് ലോഗിൻ പ്രശ്നമല്ലാതെ ഉച്ചയ്ക്കുള്ള വിച്ഛേദം പോലെ തോന്നുന്നു.

സംഖ്യാ വിലാസവും പരാജയപ്പെട്ടാൽ നാമ വിശകലനമല്ല വിശദീകരണം, അതിനാൽ ട്രാൻസ്പോർട്ടിലേക്ക് പോകുക. നിങ്ങൾ പരിശോധിച്ച വിലാസം സൂക്ഷിക്കുക, കാരണം പാക്കറ്റുകൾ യന്ത്രം വിട്ടിട്ടുണ്ടോ എന്ന് അത് അടുത്ത പരിശോധനയോട് പറയും.

ട്രാൻസ്പോർട്ട് ഫിൽട്ടറിംഗ്: ആദ്യം UDP, ബാക്കപ്പായി TCP 443

UDP 1194-ലൂടെയുള്ള OpenVPN പ്രവാഹം ഹോട്ടൽ ഫയർവാൾ തിരിച്ചറിയുന്ന ഒന്നിനോടും സാമ്യമുള്ളതല്ല, അതിനാൽ പിഴവില്ലാതെ ഉപേക്ഷിക്കപ്പെടുന്നു. ക്ലയന്റ് അതിന്റെ സമയപരിധി തീരുന്നതുവരെ വീണ്ടും ശ്രമിക്കുന്നു, ഉപയോക്താവ് നിരസിക്കലിനു പകരം ഒരിക്കലും സ്ഥാപിക്കപ്പെടാത്ത ബന്ധം കാണുന്നു. ഇങ്ങനെ പെരുമാറുന്ന ഫയർവാളുകൾ ഉപേക്ഷിക്കലുകൾ നിങ്ങൾക്ക് കാണാവുന്നിടത്ത് അപൂർവമായി മാത്രം രേഖപ്പെടുത്തുന്നു. നിരസിക്കലിന്റെ അഭാവം തന്നെയാണ് സൂചന.

TCP 443 വിശ്വസനീയമായ ബാക്കപ്പാണ്, കാരണം നെറ്റ്വർക്കിന് അതിനെ സാധാരണ HTTPS-ൽ നിന്ന് വേർതിരിച്ചറിയാനാവില്ല. ഓപ്പറേറ്ററുടെ TCP പ്രൊഫൈൽ ഉള്ളപ്പോൾ അത് ഉപയോഗിക്കുക, കാരണം സെർവറും ആ ട്രാൻസ്പോർട്ടിലും പോർട്ടിലും കേൾക്കേണ്ടതുണ്ട്; ക്ലയന്റ് മാത്രം മാറ്റുന്നത് മറ്റൊരു തരം പരാജയമുണ്ടാക്കുന്നു. TCP പ്രൊഫൈൽ ഇല്ലെങ്കിൽ പോർട്ട് തിരുത്തി പുതിയത് കണ്ടുപിടിക്കുന്നതിനു പകരം ഓപ്പറേറ്ററിനോട് ചോദിക്കുക. സെർവർ ഭാഗവും സമ്മതിക്കണം, പൊരുത്തക്കേട് വീണ്ടും ഫയർവാൾ പ്രശ്നം പോലെ തോന്നും.

പ്രകടനത്തിന്റെ വില പ്രതീക്ഷിക്കുക. TCP-യ്ക്കുള്ളിലെ TCP നഷ്ടമുള്ള ലിങ്കിൽ വീണ്ടും അയയ്ക്കൽ വർദ്ധിപ്പിക്കുന്നു, അതിനാൽ പ്രവർത്തിക്കുന്ന TCP ടണൽ തിരക്കുള്ള ഹോട്ടൽ നെറ്റ്വർക്കിൽ മന്ദഗതിയിലായി തോന്നാം. അത് പ്രാപ്യതയ്ക്കുള്ള കൈമാറ്റമാണ്, പിന്തുടരേണ്ട തകരാറല്ല.

വിലാസ കൂട്ടിയിടികളും IPv4 ഇല്ലാത്ത അപ്ലിങ്കുകളും

ടണൽ സ്ഥാപിക്കപ്പെട്ടിട്ടും ഒന്നും കൊണ്ടുപോകാതിരിക്കാം. പ്രാദേശിക LAN-ഉം വിദൂര നെറ്റ്വർക്കും 192.168.1.0/24 പോലുള്ള ഒരു പ്രിഫിക്സ് പങ്കിടുമ്പോൾ, ക്ലയന്റ് വിദൂര ഹോസ്റ്റിനെ നേരിട്ട് ബന്ധിപ്പിച്ചതായി കണക്കാക്കി പാക്കറ്റ് ടണലിനു പകരം പ്രാദേശിക ലിങ്കിലേക്ക് അയയ്ക്കുന്നു. ലക്ഷണം എത്തിച്ചേരാനാവാത്ത ഒരു സബ്നെറ്റുള്ള വിജയകരമായ ബന്ധമാണ്, അതിനെ സെർവർ ഭാഗത്തെ റൂട്ട് പ്രശ്നമായി തെറ്റായി വായിക്കുന്നത് എളുപ്പമാണ്.

ശാശ്വതമായ പരിഹാരം വിദൂര LAN അസാധാരണമായ ഒരു സ്വകാര്യ ശ്രേണിയിലേക്ക് മാറ്റുകയാണ്. വീട്ടിൽ ആരും ഉപയോഗിക്കാത്ത ശ്രേണി തിരഞ്ഞെടുക്കുന്നത്, ഉദാഹരണത്തിന് 10.42.0.0/24, ഒരിടത്തിനു പകരം എല്ലാ ഭാവി സ്ഥലങ്ങൾക്കും പ്രശ്നം തടയുന്നു. പ്രാദേശിക പരിഹാരം ആ ഹോട്ടലോ ഹോട്ട്സ്പോട്ടോ റൂട്ടറോ ഒഴിവാക്കുകയാണ്, അത് പരിഹാരമേയല്ല.

മൊബൈൽ അപ്ലിങ്കുകൾ രണ്ട് വകഭേദങ്ങൾ കൂട്ടിച്ചേർക്കുന്നു. ഓപ്പറേറ്റർ തലത്തിലുള്ള NAT അർത്ഥം ഇൻബൗണ്ട് ബന്ധങ്ങൾ എത്തുന്നില്ല എന്നാണ്, സെർവർ ഹോസ്റ്റ് ചെയ്യുന്നുവെങ്കിൽ അത് പ്രധാനമാണ്, പുറത്തേക്ക് പോകുന്ന ക്ലയന്റിന് അല്ല. NAT64 വിവർത്തനത്തോടെ IPv6 മാത്രമായി ക്രമീകരിച്ച APN, യഥാർത്ഥ IPv4 പാത ആവശ്യപ്പെടുന്ന ക്ലയന്റിനെ പരാജയപ്പെടുത്താം, സാധാരണ പരിഹാരം APN പ്രോട്ടോക്കോൾ IPv4 അല്ലെങ്കിൽ ഇരട്ട സ്റ്റാക്കിലേക്ക് മാറ്റുകയാണ്.

ടണൽ ഉയർന്നതിനു ശേഷമുള്ള ലക്ഷണങ്ങൾ

ബന്ധിപ്പിച്ചതിനു ശേഷം നിശബ്ദമാകുന്ന ടണൽ സാധാരണയായി keepalive അല്ലെങ്കിൽ MTU പ്രശ്നമാണ്, തടഞ്ഞ പോർട്ടല്ല. ഒരു നിശ്ചിത മിനിറ്റുകൾക്ക് ശേഷം വീഴുന്ന ബന്ധം keepalive അല്ലെങ്കിൽ പുനർചർച്ചാ ടൈമറിലേക്ക് വിരൽ ചൂണ്ടുന്നു. ഉത്തരങ്ങൾ നിലയ്ക്കുമ്പോൾ ക്ലയന്റിനെ അതിന്റെ പങ്കാളിയെ പരിശോധിച്ച് വീണ്ടും തുടങ്ങാൻ ക്രമീകരിക്കുക, ping വിജയിക്കുകയും വലിയ കൈമാറ്റങ്ങൾ കുടുങ്ങുകയും ചെയ്താൽ ചെറിയ ടണൽ MTU പരിശോധിക്കുക.

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