OpenVPN-നുള്ളിൽ TLS എവിടെയാണ്, എന്താണ് രൂപം മാറ്റുന്നത്
OpenVPN അതിന്റെ നിയന്ത്രണ ചാനലിനായി TLS സ്വന്തം ഫ്രെയിമിനുള്ളിൽ പ്രവർത്തിപ്പിക്കുന്നു, അതിനാൽ ആദ്യ ബൈറ്റുകൾ വെബ് ഹാൻഡ്ഷേക്ക് അല്ല. മൂന്ന് ഓപ്ഷനുകൾ മാത്രമാണ് കാണുന്നത് മാറ്റുന്നത്.
OpenVPN യഥാർത്ഥത്തിൽ TLS ഉപയോഗിക്കുന്നു, ആളുകൾ അത് അതിന് വഹിക്കാൻ കഴിയാത്ത ഒരു വാദമായി വ്യാപിപ്പിക്കുന്നു: ടണൽ അതുകൊണ്ട് സൈറ്റ് സന്ദർശിക്കുന്ന ബ്രൗസർ പോലെ കാണപ്പെടുന്നു എന്ന്. ആദ്യ ഭാഗം ശരിയാണ്. രണ്ടാമത്തേത് അല്ല. ഇവിടെ TLS OpenVPN-ന്റെ സ്വന്തം കണ്ടെയ്നറിനുള്ളിൽ സഞ്ചരിക്കുന്ന നിയന്ത്രണ ചാനലിനുള്ളതാണ്, അതിനൊപ്പം തികച്ചും വ്യത്യസ്ത ക്രിപ്റ്റോഗ്രാഫിയുള്ള പേലോഡ് ചാനലുണ്ട്, അതിനാൽ തുറക്കുന്ന ബൈറ്റുകൾ പരിശോധിക്കുന്നയാൾ OpenVPN കാണുന്നു.
ഒരു എൻവലപ്പിൽ രണ്ട് സംഭാഷണങ്ങൾ
ഒരു സെഷനെ ഒരു എൻവലപ്പ് പങ്കിടുന്ന രണ്ട് സംഭാഷണങ്ങളായി കരുതുക. ഒന്ന് സർട്ടിഫിക്കറ്റുകൾ സാധൂകരിച്ച് കീ മെറ്റീരിയൽ ഉരുത്തിരിയ്ക്കുന്നു. മറ്റൊന്ന് നിങ്ങൾ യഥാർത്ഥത്തിൽ അയയ്ക്കുന്നത് ആദ്യത്തേത് ഉൽപ്പാദിപ്പിച്ചത് കൊണ്ട് എൻക്രിപ്റ്റ് ചെയ്യുന്നു.
എൻവലപ്പ് തന്നെയാണ് പ്രോട്ടോക്കോൾ. ഓരോ പാക്കറ്റും അതിന്റെ തരം പേരിടുന്ന ചെറിയ ഹെഡറിൽ തുടങ്ങുന്നു, ആ ഹെഡർ മറ്റെല്ലാറ്റിനും മുമ്പേ വരുന്നു.
യഥാർത്ഥത്തിൽ ആദ്യം വരുന്നത്
ആ ക്രമം കാരണം വയറിൽ ആദ്യത്തേത് TLS റെക്കോർഡ് അല്ല. അത് OpenVPN-ന്റെ ഹെഡറാണ്, തുടർന്ന് ഹെഡർ പ്രഖ്യാപിക്കുന്ന ചാനലിന്റെ ഉള്ളടക്കം വരുന്നു. അവിടെ ഒരു ClientHello ഉണ്ട്, പക്ഷേ പൂജ്യം ബൈറ്റിൽ അല്ല. വ്യത്യാസം ശ്രദ്ധിക്കാൻ ഡീക്രിപ്ഷൻ ആവശ്യമില്ല, കാരണം രൂപം തന്നെ അത് വെളിപ്പെടുത്തുന്നു.
സ്ഥിരസ്ഥിതികളും ഇവിടെ പ്രധാനമാണ്. പ്രൊഫൈൽ TCP തിരഞ്ഞെടുക്കുന്നില്ലെങ്കിൽ പ്രവാഹം UDP ആയി 1194-ലേക്ക് പോകുന്നു. രണ്ട് സന്ദർഭങ്ങളിലും പുറംരൂപം ടണലാണ്, വെബ് അഭ്യർത്ഥനയല്ല.
രൂപം മാറ്റാനുള്ള മൂന്ന് സത്യസന്ധമായ വഴികൾ
stunnel പോലുള്ള TLS ടെർമിനേറ്റർ ഇരു അറ്റത്തും ഒരു പോർട്ടിൽ TLS സ്വീകരിച്ച് ഡീക്രിപ്റ്റ് ചെയ്ത പ്രവാഹം പ്രാദേശികമായി OpenVPN-ന് കൈമാറുന്നു, അതിനാൽ നെറ്റ്വർക്ക് ആ പോർട്ടിലേക്ക് TLS കാണുന്നു. ആദ്യ ബൈറ്റിൽ നിന്ന് TLS ആയ പ്രോട്ടോക്കോൾ വേറെ രീതിയിൽ പെരുമാറുന്നു: ocserv നടപ്പാക്കുന്ന AnyConnect-അനുയോജ്യമായ കൈമാറ്റം പല നെറ്റ്വർക്കുകളും ഇതിനകം പ്രതീക്ഷിക്കുന്ന കോർപ്പറേറ്റ് റിമോട്ട് ആക്സസിനോട് സാമ്യമുള്ളതാണ്. Windows-നൊപ്പം വരുന്ന SSTP മറ്റൊരു ഉൽപ്പന്നത്തിൽ അതേ സ്വഭാവം ഉണ്ട്.
Linux-ൽ, SSH-ന്റെ -w ഓപ്ഷൻ SSH സെഷനുള്ളിൽ പോയിന്റ്-ടു-പോയിന്റ് ലിങ്ക് വഹിക്കുന്നു, SSH മാത്രം അനുവദിച്ച പ്രോട്ടോക്കോൾ ആകുമ്പോൾ ഇത് ഉപയോഗപ്രദമാണ്. ആ നെറ്റ്വർക്കിൽ നിന്ന് SSH ഇതിനകം പ്രവർത്തിക്കുന്നെങ്കിൽ നാലിൽ ഏറ്റവും വിലകുറഞ്ഞത് ഇതാണ്, ഇല്ലെങ്കിൽ ഏറ്റവും കുറച്ച് ഉപയോഗപ്രദവും.
അവയൊന്നും മാറ്റാത്തത്
ഇവയൊന്നും ടണലിന് എത്താൻ കഴിയുന്ന ദൂരം മാറ്റുന്നില്ല. അവ തടയപ്പെട്ട വിലാസം എത്താവുന്നതാക്കുന്നില്ല, ആരെയും പ്രമാണീകരിക്കുന്നില്ല, കൂടാതെ റൂട്ടുകൾ തീരുമാനിക്കുന്നുമില്ല.
ഒരു പൊതിയും നിങ്ങൾക്ക് ഒരു ഘടകം ചെലവാക്കുന്നു. രണ്ട് ശ്രോതാക്കളും രണ്ട് കോൺഫിഗറേഷൻ ഫയലുകളും എന്നാൽ പരാജയത്തിന് രണ്ട് സ്ഥലങ്ങൾ, രണ്ടും ഉപയോക്താവിന്റെ ഇരിപ്പിടത്തിൽ നിന്ന് ഒരേപോലെ കാണപ്പെടുന്നു. ഒന്ന് സ്വീകരിക്കുന്നതിന് മുമ്പ് അത് ബജറ്റിൽ ഉൾപ്പെടുത്തുക. സെഷൻ ഒരു ലക്ഷ്യത്തിലേക്കുള്ള ഒരൊറ്റ ദീർഘകാല എൻക്രിപ്റ്റ് പ്രവാഹമായി തുടരുന്നു, അതിന്റെ അളവും സമയവും കാണാവുന്നതായി തുടരുന്നു.
ആദ്യം രോഗനിർണയം, പിന്നീട് തിരഞ്ഞെടുപ്പ്
അതിനാൽ ആദ്യം രോഗനിർണയം ചെയ്യുക. ഉപേക്ഷിക്കപ്പെട്ട UDP-യ്ക്ക് TCP മോഡ് ഉത്തരം നൽകുന്നു, തിരിച്ചറിഞ്ഞ ഒപ്പത്തിന് മറ്റൊരു പ്രോട്ടോക്കോൾ അല്ലെങ്കിൽ ഒരു പൊതി ഉത്തരം നൽകുന്നു. തടയൽ അറിയുന്നതിന് മുമ്പ് ഉപകരണം തിരഞ്ഞെടുക്കുന്നതാണ് ഒരേ കാരണത്താൽ എല്ലാം പരാജയപ്പെടുന്ന മൂന്ന് പാളികൾ പരിപാലിക്കുന്നതിൽ ആളുകൾ എത്തുന്ന വഴി.
വെബ് പോർട്ടുകൾ മാത്രം അനുവദിക്കുന്ന നെറ്റ്വർക്ക് തിരഞ്ഞെടുപ്പിനെ 443-ലെ TLS അധിഷ്ഠിത പ്രോട്ടോക്കോളിലേക്ക് ചുരുക്കുന്നു. മൂന്നും ഒരുമിച്ച് പ്രയോഗിച്ചാൽ ആർക്കും ഡീബഗ് ചെയ്യാൻ കഴിയാത്ത ഒരു സ്റ്റാക്ക് ലഭിക്കും, അതിനാൽ ഒരു കാര്യം മാറ്റി അതേ പ്രവാഹം വീണ്ടും പരിശോധിക്കുക.
അവയൊന്നും ബാധകമല്ലെങ്കിൽ, കൃത്യമായ ഉത്തരം ഈ നെറ്റ്വർക്ക് നിങ്ങൾക്കായി ടണൽ വഹിക്കില്ല എന്നതാണ്. അത് ശ്രമത്തിന്റെ പരാജയമല്ല, ഒരു കണ്ടെത്തലാണ്. കൂടുതൽ ഓപ്ഷനുകളിലൂടെ കറങ്ങുന്നത് മേലെ എടുത്ത നയ തീരുമാനം തിരിച്ചുമറിക്കുന്നില്ല.
ഇവയെല്ലാറ്റിനും മുന്നിൽ ഒരു അതിർത്തി നിൽക്കുന്നു. മറ്റൊരാളുടെ നെറ്റ്വർക്കിൽ ടണൽ പ്രവർത്തിപ്പിക്കാനുള്ള അനുമതി ഒരു നയ വിഷയമാണ്, അത് സംവിധാനം പ്രവർത്തിക്കുന്നുണ്ടോ എന്നതിൽ നിന്ന് വേറിട്ട് തീരുമാനിക്കുന്നു. ഈ വസ്തുതകൾ നിരീക്ഷകൻ എന്ത് കാണുന്നു എന്ന് വിശദീകരിക്കുന്നു, അവ അനുമതി നൽകുന്നുമില്ല.