UDP എപ്പോഴും വേഗത്തിലല്ല: OpenVPN ട്രാൻസ്പോർട്ട് തിരഞ്ഞെടുക്കൽ

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

ട്രാൻസ്പോർട്ട് യഥാർത്ഥത്തിൽ എന്ത് മാറ്റുന്നു

TCP വിശ്വസനീയവും ക്രമീകൃതവുമായ ബൈറ്റ് സ്ട്രീം നൽകുന്നു, നഷ്ടപ്പെട്ടതെല്ലാം വീണ്ടും അയയ്ക്കുന്നു, RFC 9293 വ്യക്തമാക്കുന്നതുപോലെ. UDP ഡാറ്റാഗ്രാമുകൾ നെറ്റ്വർക്കിന് കൈമാറുന്നു, OpenVPN ആ സോക്കറ്റിന് മുകളിൽ സ്വന്തം വിശ്വസനീയതാ പാളി പ്രവർത്തിപ്പിക്കുന്നു. TCP-യെ TCP-യ്ക്കുള്ളിൽ എൻകാപ്സുലേറ്റ് ചെയ്യുന്നത് രണ്ട് വീണ്ടെടുക്കൽ ലൂപ്പുകൾ കൂട്ടിവയ്ക്കുന്നു, അതിനാൽ നഷ്ടപ്പെട്ട ഒരു സെഗ്മെന്റിന് ആന്തരിക സ്ട്രീം തടഞ്ഞുനിർത്താം, പുറത്തെ വീണ്ടും അയയ്ക്കൽ എത്തുന്നതുവരെ. ആ പരസ്പരപ്രവർത്തനമാണ് UDP-യ്ക്കുള്ള യഥാർത്ഥ വാദം, അത് ത്രൂപുട്ടായല്ല, ലേറ്റൻസിയായി പ്രത്യക്ഷപ്പെടുന്നു.

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

ഇവയൊന്നും രഹസ്യസ്വഭാവത്തെയോ സമഗ്രതയെയോ സ്പർശിക്കുന്നില്ല. TLS ഹാൻഡ്ഷേക്കും ഡാറ്റാ ചാനൽ സൈഫറും രണ്ട് ട്രാൻസ്പോർട്ടുകൾക്കും ഒരുപോലെയാണ്, അതിനാൽ മാറ്റുന്നത് ദുർബലമായ സൈഫർ സ്യൂട്ട് രക്ഷിക്കില്ല.

TCP അതിന്റെ സ്ഥാനം നേടുന്നിടത്ത്

ആക്സസ് നെറ്റ്വർക്കുകളാണ് TCP തിരഞ്ഞെടുക്കാനുള്ള സാധാരണ കാരണം. ഹോട്ടൽ, വിമാനത്താവളം അല്ലെങ്കിൽ ഗസ്റ്റ് നെറ്റ്വർക്ക് പുറത്തേക്കുള്ള 443 അനുവദിച്ച് ബാക്കിയെല്ലാം ഉപേക്ഷിച്ചേക്കാം, ആ പോർട്ടിലെ TCP ലിസ്നർ മാത്രമാണ് പ്രവർത്തിക്കുന്ന പ്രൊഫൈൽ. ഇത് എത്തിച്ചേരലാണ്, പ്രകടനമല്ല, സ്വതന്ത്രമായി അത് മതിയായ കാരണമാണ്.

പാത സ്ഥിരമായിരുന്നാലും ഇടനില ബോക്സുകൾ ശത്രുതാപരമായിരുന്നാലും TCP സഹായിക്കുന്നു. ചില നെറ്റ്വർക്കുകൾ സാധാരണ വെബ് ട്രാഫിക്കിന് സമാനമായ TCP സെഷനുകൾ സഹിച്ച് ദീർഘകാല UDP ഫ്ലോകൾ റീസെറ്റ് ചെയ്യുന്നു. ആ സാമ്യം വിജയിക്കുന്നുണ്ടോ എന്നത് പ്രത്യേക നെറ്റ്വർക്കിന്റെ സ്വഭാവമാണ്, ഏത് ഗൈഡിനും എല്ലാവർക്കും അത് വാഗ്ദാനം ചെയ്യാനാവില്ല. പ്രോട്ടോക്കോളിനെ കുറ്റപ്പെടുത്തുന്നതിന് മുമ്പ് പരാജയപ്പെടുന്ന നെറ്റ്വർക്കിനുള്ളിൽ പരീക്ഷിക്കുക.

നിരസിക്കപ്പെട്ട ലോഗിൻ ട്രാൻസ്പോർട്ട് പ്രശ്നമല്ല. കണക്ഷൻ നിർബന്ധിച്ച് കടത്താൻ സർട്ടിഫിക്കറ്റ് പരിശോധന ഓഫ് ചെയ്യുന്നത് മറ്റൊരു മാറ്റമാണ്, വളരെ മോശം ഫലത്തോടെ.

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

യഥാർത്ഥത്തിൽ ഏത് ലിസ്നറാണ് നിങ്ങൾക്കുള്ളതെന്ന് പരിശോധിക്കുക

പ്രകടനം താരതമ്യം ചെയ്യുന്നതിന് മുമ്പ് ഇരു വശങ്ങളും ട്രാൻസ്പോർട്ടിലും പോർട്ടിലും യോജിക്കുന്നുവെന്ന് ഉറപ്പാക്കുക. ക്ലയന്റ് ഫയലിൽ proto udp proto tcp ആക്കി മാറ്റുന്നത് സർവർ ലിസ്നർ സൃഷ്ടിക്കുന്നില്ല. സർവർ ആ പ്രോട്ടോക്കോളിനായി കോൺഫിഗർ ചെയ്തിരിക്കണം, പ്രൊഫൈൽ അതുമായി പൊരുത്തപ്പെടണം.

grep -E '^(proto|port|remote)' /etc/openvpn/server.conf
ss -lunp | grep openvpn
ss -ltnp | grep openvpn

grep സർവറിനോട് എന്ത് ഉപയോഗിക്കാൻ പറഞ്ഞുവെന്ന് പ്രിന്റ് ചെയ്യുന്നു, രണ്ട് സോക്കറ്റ് ലിസ്റ്റുകൾ അത് എന്തിലേക്ക് ബൈൻഡ് ചെയ്തിരിക്കുന്നുവെന്ന് കാണിക്കുന്നു. UDP ലിസ്നർ ആദ്യ ലിസ്റ്റിൽ മാത്രം, TCP ലിസ്നർ രണ്ടാമത്തേതിൽ മാത്രം ദൃശ്യമാകുന്നു, അതിനാൽ കാണാത്ത വരിയാണ് ഒരിക്കലും പ്രയോഗിക്കാത്ത പ്രൊഫൈൽ കണ്ടെത്താനുള്ള ഏറ്റവും വേഗമേറിയ വഴി. പോർട്ടും താരതമ്യം ചെയ്യുക, കാരണം 1194-ലെ TCP പ്രൊഫൈൽ മിക്ക ആക്സസ് നെറ്റ്വർക്കുകളിലും 443-ലേതിൽനിന്ന് വ്യത്യസ്തമായി പെരുമാറുന്നു. മാറ്റത്തിന് ശേഷം സേവനം പുനരാരംഭിച്ച് ബൈൻഡിംഗ് റിപ്പോർട്ട് ചെയ്യുന്ന ലോഗ് വരി വായിക്കുക.

ക്ലയന്റ് വശത്തെ സ്ഥിരീകരണം വിലകുറഞ്ഞതാണ്: --verb 4 ഉപയോഗിച്ച് കണക്ഷൻ പ്രവർത്തിപ്പിച്ച് ലോഗിലെ ട്രാൻസ്പോർട്ട് വരി വായിക്കുക. ക്ലയന്റ് UDP എന്ന് പറയുമ്പോൾ സർവർ TCP-യിൽ കേൾക്കുന്നുവെങ്കിൽ, ഹാൻഡ്ഷേക്ക് ഒരിക്കലും തുടങ്ങുന്നില്ല, ഏത് ട്യൂണിംഗും സഹായിക്കില്ല.

ട്രാൻസ്പോർട്ട് ലേബലല്ല, ജോലിഭാരം താരതമ്യം ചെയ്യുക

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

ഓരോ റണ്ണിനും മൂന്ന് ഫലങ്ങൾ രേഖപ്പെടുത്തുക: ടണൽ സ്ഥാപിക്കുന്നുവോ, നിലനിൽക്കുന്നുവോ, ജോലി പൂർത്തിയാകുന്നുവോ. വലിയ കൈമാറ്റങ്ങൾ കുടുങ്ങുമ്പോൾ ചെറിയ അഭ്യർത്ഥനകൾ പ്രവർത്തിച്ചാൽ അത് ട്രാൻസ്പോർട്ടല്ല, പാക്കറ്റ് വലിപ്പത്തെയും MTU-യെയും സൂചിപ്പിക്കുന്നു. ആവർത്തിച്ചുള്ള പുനർബന്ധനങ്ങൾ പാതയെയോ ഇടനില ബോക്സിന്റെ സമയപരിധിയെയോ സൂചിപ്പിക്കുന്നു.

നിങ്ങൾ യഥാർത്ഥത്തിൽ നേരിടുന്ന സാഹചര്യങ്ങളിൽ പ്രവർത്തിക്കുന്ന പ്രൊഫൈൽ സൂക്ഷിക്കുക, മറ്റൊന്ന് സേവ് ചെയ്യുക. തിരഞ്ഞെടുപ്പ് വ്യക്തിയുടേതല്ല, നെറ്റ്വർക്കിന്റേതാണ്, അതിനാൽ ഏതെങ്കിലും ഒരു സ്വതവേയുള്ള ഉത്തരം എവിടെയോ തെറ്റാണ്.