HTTP പ്രോക്സി വഴി OpenVPN: ആദ്യം CONNECT മറുപടി വായിക്കുക
CONNECT പ്രോക്സി ബൈറ്റുകൾ കൈമാറുന്നു, അതിനാൽ ഇരു വശത്തിനും TCP വേണം. സർട്ടിഫിക്കറ്റുകളെ കുറ്റപ്പെടുത്തുന്നതിന് മുമ്പ് 407, 403, 503 വായിക്കുക, സർവർ പരിശോധന ഓണാക്കി വയ്ക്കുക.
VPN ക്ലയന്റ് ഒരു കോർപ്പറേറ്റ് HTTP പ്രോക്സിലേക്ക് തിരിക്കുക, ആദ്യ ഉപയോഗപ്രദമായ വസ്തുത പ്രോക്സി VPN-ന്റെ പ്രോട്ടോക്കോൾ സംസാരിക്കുന്നില്ല എന്നതാണ്. അത് നിങ്ങൾ പറഞ്ഞ വിലാസത്തിലേക്ക് സാധാരണ TCP കണക്ഷൻ തുറന്ന് പിന്നീട് മാറിനിൽക്കുന്നു, ക്ലയന്റും സർവറും ആ സ്ട്രീമിലൂടെ സ്വന്തം കൈമാറ്റം നടത്തുന്നു. ക്ലയന്റിന് വേണ്ടതെല്ലാം, ട്രാൻസ്പോർട്ട് തരം മുതൽ സർവറിന്റെ ശ്രോതാവ് വരെ, ഈ ക്രമീകരണവുമായി പൊരുത്തപ്പെടണം. രണ്ട് പൊരുത്തക്കേടുകൾ മിക്ക പരാജയങ്ങളും വിശദീകരിക്കുന്നു: CONNECT പ്രോക്സിലേക്ക് ലക്ഷ്യമിട്ട UDP പ്രൊഫൈൽ, VPN പിശകായി തെറ്റിദ്ധരിച്ച പ്രോക്സി മറുപടി.
പ്രോക്സി എന്താണ് വഹിക്കുന്നത്, എന്തല്ല
പ്രോക്സി ഒരു ട്രാൻസ്പോർട്ട് ഘട്ടം മാത്രമാണ്. അത് നിങ്ങളുടെ ബ്രൗസർ പ്രോക്സിയാകുന്നില്ല, ടണലിലൂടെ നിങ്ങൾ സന്ദർശിക്കുന്ന സൈറ്റുകൾ കാഷെ ചെയ്യുന്നില്ല, ആരെങ്കിലും ബോധപൂർവം പരിശോധന ക്രമീകരിച്ചില്ലെങ്കിൽ ആന്തരിക ട്രാഫിക് കാണുന്നുമില്ല. അത് തുറക്കുന്ന ടണൽ രൂപകൽപ്പനയാൽ അതിന് അതാര്യമാണ്.
അതായത് പൊരുത്തപ്പെടുന്ന ശ്രോതാവില്ലാത്ത സർവറിനെ പ്രോക്സിക്ക് ശരിയാക്കാനാവില്ല. ഒരു ലക്ഷ്യസ്ഥാനത്ത് എത്താനുള്ള അനുമതിയും ആ ലക്ഷ്യസ്ഥാനത്ത് കേൾക്കുന്ന സേവനവും രണ്ട് വേറിട്ട വസ്തുതകളാണ്, ആദ്യത്തേത് മാത്രമാണ് പ്രോക്സി അഡ്മിനിസ്ട്രേറ്ററുടേത്.
വാഹകൻ ഇരു വശത്തും TCP ആയിരിക്കണം
സാധാരണ CONNECT പ്രോക്സി ഒരു ബൈറ്റ് സ്ട്രീം മാത്രം കൈമാറുന്നു , അതിനാൽ ക്ലയന്റ് സ്ട്രീം ട്രാൻസ്പോർട്ട് ഉപയോഗിക്കണം. ആ സന്ദർഭത്തിനുള്ള ക്ലയന്റ് ഭാഗം ഇങ്ങനെ കാണാം:
proto tcp-client
remote vpn.example.net 1194
http-proxy proxy.corp.example 3128സർവർ വശത്തിന് remote വരിയിൽ പറഞ്ഞ പോർട്ടിൽ യഥാർത്ഥ TCP ശ്രോതാവ് വേണം. പ്രൊഫൈലിൽ proto udp എന്നത് proto tcp-client ആക്കി മാറ്റുന്നത് സ്ട്രീം പ്രതീക്ഷിക്കുന്ന ക്ലയന്റ് ഉണ്ടാക്കുന്നു; അത് മറുവശത്ത് സ്ട്രീം ഉണ്ടാക്കുന്നില്ല. അതേ സർവർ ആ പോർട്ടിൽ UDP വഴിയും മറുപടി നൽകിയാൽ അത് മറ്റൊരു ശ്രോതാവാണ്, അതേ ശ്രോതാവിന്റെ രണ്ടാം മോഡ് അല്ല.
വേറിട്ട TCP ഇൻസ്റ്റൻസ് ഉള്ളിടത്ത്, അതിന്റെ ടണൽ ഉപകരണവും വിലാസ കൂട്ടവും റൂട്ടിംഗും സ്വന്തം വിഭവങ്ങളാണ്. പ്രവർത്തിക്കുന്ന കോൺഫിഗറേഷൻ പകർത്തി ട്രാൻസ്പോർട്ട് പദം മാറ്റുന്നത് ആ വിഭവങ്ങളെ യഥാർത്ഥ ഇൻസ്റ്റൻസിലേക്ക് തന്നെ ചൂണ്ടിക്കാണിക്കാൻ വിടുന്നു, ഇത് പ്രാമാണീകരണം നടത്തി പിന്നീട് ഒന്നും റൂട്ട് ചെയ്യാത്ത കണക്ഷൻ ഉണ്ടാക്കുന്നു.
VPN ഫലത്തിന് മുമ്പ് പ്രോക്സി മറുപടി വായിക്കുക
ക്ലയന്റിന്റെ ആദ്യ കൈമാറ്റം ലക്ഷ്യ ഹോസ്റ്റും പോർട്ടും പേരിടുന്ന അഭ്യർത്ഥന വരിയാണ്. ആ വരിയിലെ മറുപടി ബൈറ്റ് സ്ട്രീം ഉണ്ടോ ഇല്ലയോ എന്ന് പറയുന്നു, ഏതെങ്കിലും സർട്ടിഫിക്കറ്റോ ക്രെഡൻഷ്യലോ പരിശോധിക്കുന്നതിന് മുമ്പ് അത് എത്തുന്നു:
CONNECT vpn.example.net:1194 HTTP/1.1
Host: vpn.example.net:1194| Proxy reply | What it means | Where to look next |
|---|---|---|
407 Proxy Authentication Required | The proxy wants its own credentials | The client's proxy auth options, not the VPN account |
403 Forbidden | The destination or method is not permitted | The proxy's access policy for that host and port |
503 Service Unavailable | The proxy could not complete the upstream connection | The proxy's own logs and the server's listener |
CONNECT-ന് 200 ക്ലാസ് മറുപടി എന്നാൽ സ്ട്രീം ഉണ്ട്. ഗേറ്റ്വേ സർട്ടിഫിക്കറ്റ് വിശ്വസനീയമാണോ, പങ്കിട്ട കീ ഒത്തുപോകുന്നുണ്ടോ, ഉപയോക്തൃ അക്കൗണ്ട് സാധുവാണോ എന്നൊന്നും അത് പറയുന്നില്ല. ആ പരിശോധനകൾ പിന്നീട്, സ്ട്രീമിനുള്ളിൽ നടക്കുന്നു, അവ HTTP സ്റ്റാറ്റസ് വരിയല്ല, ക്ലയന്റിന്റെ സ്വന്തം സന്ദേശങ്ങളിലാണ് പരാജയപ്പെടുന്നത്. ക്ലയന്റ് ലോഗിൽ ആദ്യ OpenVPN സംഭവം പ്രോക്സി ഹാൻഡ്ഷേക്കിന് ശേഷം നോക്കുക, വിൻഡോ അടയ്ക്കുന്നതിന് മുമ്പുള്ള അവസാന വരിയല്ല.
പ്രോക്സി ക്രെഡൻഷ്യലുകളും VPN ക്രെഡൻഷ്യലുകളും പലപ്പോഴും വേറിട്ട ടീമുകളുടെ കൈവശമുള്ള വേറിട്ട ഐഡന്റിറ്റികളാണ്. 407 VPN അക്കൗണ്ടിന്റെ മോശം പാസ്വേഡല്ല, നിരസിച്ച സർട്ടിഫിക്കറ്റ് പ്രോക്സി അനുമതി പ്രശ്നവുമല്ല.
CONNECT വെളിപ്പെടുത്താത്തത്
വ്യക്തമായ CONNECT ടണൽ ചോർന്നുകേൾക്കലല്ല. പ്രോക്സി ബൈറ്റുകൾ കൈമാറുന്നു, VPN-ന്റെ TLS സെഷൻ അവസാനിപ്പിക്കുന്നില്ല, അതിനാൽ സർവർ സർട്ടിഫിക്കറ്റിന്റെ ക്ലയന്റ് പരിശോധന അർത്ഥവത്തായി തുടരുന്നു, ഓണായി തന്നെയിരിക്കണം. പ്രോക്സി കടക്കാൻ പരിശോധന ഓഫാക്കുന്നത് നിങ്ങളുടെ പ്രശ്നത്തിൽ നിന്ന് വ്യത്യസ്തമായ പ്രശ്നം പരിഹരിക്കുന്നു.
ഒരു സ്ഥാപനം ബോധപൂർവം TLS അവസാനിപ്പിച്ച് പരിശോധിക്കുന്ന വേറിട്ട ക്രമീകരണങ്ങളുണ്ട്. അവയ്ക്ക് സ്വന്തം വിശ്വാസ കോൺഫിഗറേഷനും സ്വന്തം നയ തീരുമാനവും വേണം, സാധാരണ http-proxy വരി ആവശ്യപ്പെടുന്നത് അവയല്ല.
TCP-യ്ക്കുള്ളിലെ TCP-യുടെ ചെലവ്
ടണൽ TCP വഴി കൊണ്ടുപോകുന്നത് പുറം സ്ട്രീമിനെ ക്രമത്തിലും പുനഃസംപ്രേഷണത്തോടെയും നിർത്തുന്നു, ആന്തരിക ട്രാഫിക്കും സാധാരണയായി TCP ആണ്. രണ്ട് വീണ്ടെടുപ്പ് സംവിധാനങ്ങൾ ഏകോപിക്കുന്നില്ല, അതിനാൽ ഒരു നഷ്ടപ്പെട്ട സെഗ്മെന്റ് ആ പുറം സ്ട്രീം പങ്കിടുന്ന എല്ലാത്തിനെയും വീണ്ടും അയയ്ക്കുന്നതുവരെ നിർത്താം. ഇത് പൊരുത്തപ്പെടുത്തലിനുള്ള യഥാർത്ഥ കൈമാറ്റമാണ്, സൗജന്യ അപ്ഗ്രേഡല്ല.
നെറ്റ്വർക്ക് മറ്റ് വഴിയില്ലാത്തപ്പോൾ പ്രോക്സി പാത ഉപയോഗിക്കുക, നയം അനുവദിക്കുന്നിടത്ത് നേരിട്ടുള്ള UDP പാതയ്ക്ക് മുൻഗണന നൽകുക. ഏതായാലും, മാറ്റത്തിന് ശേഷം അതേ പ്രോക്സി, ലക്ഷ്യം, പ്രൊഫൈൽ എന്നിവ അടുത്ത ഘട്ടത്തിൽ എത്തുന്നുവെന്ന് ഉറപ്പാക്കുക; ആ വിലാസത്തിൽ പേജ് ലോഡ് ചെയ്യുന്ന ബ്രൗസർ മറ്റൊരു പ്രോട്ടോക്കോൾ ഉപയോഗിക്കുന്നു, ടണലിനെക്കുറിച്ച് ഒന്നും തെളിയിക്കുന്നുമില്ല.