ഹോട്ടൽ Wi-Fi-ൽ OpenVPN കണക്ട് ആകുന്നില്ലേ? TCP 443 പരീക്ഷിക്കുക

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

ആദ്യം ഫോൺ ഹോട്ട്സ്പോട്ടിൽ നിന്ന് പരീക്ഷിക്കുക. അവിടെ ടണൽ ഉയരുന്നുവെങ്കിൽ, സെർവർ, സർട്ടിഫിക്കറ്റ്, അക്കൗണ്ട് എല്ലാം കുഴപ്പമില്ല, ബാക്കിയുള്ള ഒരേയൊരു ചരം നിങ്ങളുടെ മുന്നിലുള്ള നെറ്റ്വർക്കാണ്.

ക്ലൈന്റിൽ നിന്ന് തുടങ്ങുക: സ്റ്റാറ്റസ് ലൈൻ വായിക്കുക

ഏത് ഘട്ടം പരാജയപ്പെട്ടുവെന്ന് സ്റ്റാറ്റസ് ലൈൻ പറയും. കണക്ടിംഗിൽ കുടുങ്ങിയ ക്ലൈന്റ് ഇപ്പോഴും ഹോസ്റ്റ് നിർണ്ണയിക്കുകയോ പുറം സോക്കറ്റ് തുറക്കുകയോ ചെയ്യുന്നു; സെർവറിനായി കാത്തിരിക്കുന്നു എന്ന ഘട്ടത്തിലെത്തിയതിന് വഴിയുണ്ട്, മറുപടിയില്ല; ആധികാരികരിച്ച ശേഷം വീഴുന്നതിന് തികച്ചും വേറെ പ്രശ്നമാണ്. ക്ലൈന്റ് ലോഗും പ്രൊഫൈലിന്റെ സ്വന്തം remote, proto ഫീൽഡുകളും ക്ലൈന്റ് എന്ത് ചെയ്യാൻ ശ്രമിക്കുന്നുവെന്ന് കാണിക്കുന്നു, കമാൻഡ്-ലൈൻ ക്ലൈന്റിൽ --verb 4 അതേ വിശദാംശം അച്ചടിക്കുന്നു. അതിനെ നിങ്ങളുടെ മുന്നിലുള്ള നെറ്റ്വർക്കുമായി താരതമ്യം ചെയ്യുന്നതാണ് 'VPN ബ്ലോക്ക് ചെയ്തിരിക്കുന്നു' എന്നതിനെ കൃത്യമായ വാദമാക്കി മാറ്റുന്നത്.

പിന്നീട് കൈവശമുള്ള ഉപകരണങ്ങൾ കൊണ്ട് നെറ്റ്വർക്ക് പരിശോധിക്കുക. nc -vzu 203.0.113.10 1194 ഒരു UDP ഡാറ്റാഗ്രാം അയക്കുന്നു, curl -v telnet://203.0.113.10:443 TCP ഹാൻഡ്ഷേക്ക് പൂർത്തിയാകുന്നുണ്ടോ എന്ന് റിപ്പോർട്ട് ചെയ്യുന്നു, HTTPS പേജ് ലോഡ് ചെയ്യുന്ന ബ്രൗസർ പുറത്തേക്കുള്ള 443 ആ ഒരു ഹോസ്റ്റിലെത്തുന്നു എന്ന് മാത്രം തെളിയിക്കുന്നു. ചെറിയ പരിശോധനകൾ VPN ക്ലൈന്റിന് ഉത്തരം നൽകാൻ കഴിയാത്തതിന് ഉത്തരം നൽകുന്നു: ഏത് പോർട്ടും ഏത് പ്രോട്ടോക്കോളും ഈ നെറ്റ്വർക്കിൽ നിന്ന് പുറത്തുപോകുന്നു എന്നത്.

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

ലിസണറും പ്രൊഫൈലും ഒരുമിച്ച് മാറ്റുക

സെർവർ ഭാഗത്ത്, നെറ്റ്വർക്ക് അനുവദിക്കുന്നതിലേക്ക് ലിസണർ വയ്ക്കുക: സെർവർ കോൺഫിഗറേഷനിൽ port 443, proto tcp, പിന്നീട് സേവനം വീണ്ടും ആരംഭിച്ച് ss -lntp കൊണ്ട് സോക്കറ്റ് ഉറപ്പാക്കുക. ക്ലൈന്റ് ഭാഗത്ത് പ്രൊഫൈൽ യോജിക്കണം, കാരണം ട്രാൻസ്പോർട്ടും പോർട്ടും ടണലിന് പുറത്താണ്: .ovpn-ൽ proto tcp, port 443, അല്ലെങ്കിൽ ആപ്പിന്റെ ക്രമീകരണ സ്ക്രീനിലെ ബന്ധപ്പെട്ട ഫീൽഡുകൾ. ഇപ്പോഴും UDP 1194-ലേക്ക് ലക്ഷ്യമിടുന്ന പ്രൊഫൈൽ മുൻപുപോലെ തന്നെ പരാജയപ്പെടും, ഇതിനകം നന്നാക്കിയ ഫയർവാളിനെ കുറ്റപ്പെടുത്താൻ തോന്നും. അതേ ഹോസ്റ്റ് 443-ൽ HTTPS-നും ഉത്തരം നൽകുന്നുവെങ്കിൽ, രണ്ട് ലിസണർക്കും ആ വിലാസവും പ്രോട്ടോക്കോളും പങ്കിടാൻ കഴിയില്ല; VPN-ന് രണ്ടാമത് ഒരു വിലാസം നൽകുക അല്ലെങ്കിൽ മുന്നിൽ ഡീമൾട്ടിപ്ലെക്സർ വയ്ക്കുക.

ഇരു അറ്റങ്ങളിലും tcpdump -ni any port 443 ഉപയോഗിച്ച് ആദ്യ കണക്ഷൻ നിരീക്ഷിക്കുക. ക്ലൈന്റിൽ നിന്ന് പുറപ്പെട്ട് ഒരിക്കലും എത്താത്ത പാക്കറ്റുകൾ എന്നാൽ നെറ്റ്വർക്ക് എന്തായാലും ഫിൽട്ടർ ചെയ്യുന്നു, അല്ലെങ്കിൽ പ്രൊഫൈലിലെ വിലാസം നിങ്ങൾ കരുതുന്നതല്ല. മറുപടിയില്ലാതെ എത്തുന്ന പാക്കറ്റുകൾ നിങ്ങളെ സെർവർ ലോഗിലേക്ക് തിരിച്ചയക്കുന്നു, അവിടെ പ്രോട്ടോക്കോൾ പൊരുത്തക്കേട് ഉടനെ ഉപേക്ഷിച്ച പാക്കറ്റായി കാണാം.

നെറ്റ്വർക്കിൽ നിന്ന് പ്രോക്സി മാത്രം പുറത്തുപോകുമ്പോൾ

ചില അതിഥി നെറ്റ്വർക്കുകൾ HTTP പ്രോക്സി ഒഴികെ ഒന്നും അനുവദിക്കുന്നില്ല, ഇത് അടച്ച പോർട്ടിൽ നിന്ന് വ്യത്യസ്തമായ നിയന്ത്രണമാണ്, OpenVPN-നെക്കാൾ കൂടുതലിനെ ഒഴിവാക്കുന്നു. PPTP, L2TP/IPsec അല്ലെങ്കിൽ വെറും IPsec മാത്രം സംസാരിക്കുന്ന ക്ലൈന്റുകൾക്ക് അതിലൂടെ കടക്കാൻ വഴിയില്ല, കാരണം ആ രൂപകൽപ്പനകൾ അവയുടെ പുറം പ്രോട്ടോക്കോൾ സെർവറിലേക്ക് നേരിട്ട് എത്തുമെന്ന് പ്രതീക്ഷിക്കുന്നു. OpenVPN-ന് സാധിക്കും, ക്ലൈന്റ് പ്രൊഫൈലിൽ http-proxy proxy.example.net 8080 ഉണ്ടെങ്കിൽ, പ്രോക്സി നിങ്ങളുടെ പോർട്ടിലേക്ക് CONNECT രീതി അനുവദിച്ചാൽ. SOCKS പ്രോക്സി ഇനിയും എളുപ്പമാണ്, കാരണം ഉള്ളിൽ എന്താണെന്ന് നോക്കാതെ അത് സ്ട്രീം കൈമാറുന്നു.

ക്ലൈന്റിന് പ്രോക്സി പിന്തുണയില്ലാത്തിടത്ത്, 443-ലെ SSH ടണൽ സാധാരണയായി അവശേഷിക്കുന്നു. അത് ഒരു രണ്ടാം പാളി കൂട്ടിച്ചേർക്കുന്നു, നെറ്റ്വർക്കിന്റെ ഓപ്പറേറ്റർക്ക് അതിനെപ്പറ്റി അഭിപ്രായമുണ്ടാകാം, അതിനാൽ ഒരു യാത്രയുടെ പാലമായി കാണുക, ആർക്കിടെക്ചറായല്ല.

നിലനിർത്തുന്നതിന് മുൻപ് പകര വഴിയുടെ വില കണക്കാക്കുക

TCP-യ്ക്കുള്ളിൽ TCP-യ്ക്ക് അറിയപ്പെടുന്ന വിലയുണ്ട്. പുറം കണക്ഷൻ TCP ആയിരിക്കുകയും പേലോഡും TCP ആകുകയും ചെയ്യുമ്പോൾ, നഷ്ടപ്പെട്ട സെഗ്മെന്റ് രണ്ട് പാളികളിലും പുനഃപ്രേഷണം ഉണ്ടാക്കുന്നു, ഉള്ളിലെ കണക്ഷൻ കാണാൻ കഴിയാത്ത നഷ്ടത്തിൽ നിന്ന് പിന്നോട്ട് പോകുന്നു. ബ്രൗസിംഗ് അത് സഹിക്കുന്നു; ഇന്ററാക്ടീവ് സെഷനുകളും കോളുകളും അത് അനുഭവിക്കുന്നു. TCP 443 ലിസണർ അത് ആവശ്യപ്പെടുന്ന നെറ്റ്വർക്കുകൾക്കുള്ള പകര വഴിയായി നിലനിർത്തുക, ഇപ്പോഴും അത് കടത്തിവിടുന്ന എല്ലാത്തിനും UDP സ്വതവേയുള്ളതായി വിടുക.

തിരഞ്ഞെടുപ്പ് പ്രൊഫൈൽ പേരിലും പിന്തുണാ കുറിപ്പുകളിലും രേഖപ്പെടുത്തുക: ഏത് പോർട്ട്, ഏത് പ്രോട്ടോക്കോൾ, ഏത് നെറ്റ്വർക്കാണ് അതിന് കാരണമായത്. പിന്നീട്, അടുത്ത ഉപകരണ മാറ്റത്തിന് ശേഷവും ആ പോർട്ട് തുറന്നിരിക്കുമോ എന്ന് നെറ്റ്വർക്ക് അഡ്മിനിസ്ട്രേറ്ററിനോട് ചോദിക്കുക, കാരണം നിശബ്ദമായി അപ്രത്യക്ഷമാകുന്ന പകര വഴി പകര വഴിയില്ലാത്തതിനെക്കാൾ മോശമാണ്.