OpenVPN mssfix: വലിയ കൈമാറ്റങ്ങളിൽ ഒരു ക്ലയന്റ് എന്തുകൊണ്ട് നിലയ്ക്കുന്നു

ഒരു ലാപ്ടോപ്പ് ടണലിലൂടെ അപ്ലോഡിൽ നിലയ്ക്കുന്നു, അതേ സെർവറിലെ മറ്റെല്ലാ ഉപകരണങ്ങളും പ്രവർത്തിക്കുന്നത് തുടരുന്നു. ആ മാതൃക സെർവർ കോൺഫിഗറേഷനെയല്ല, ഒരു പാതയെയാണ് സൂചിപ്പിക്കുന്നത്, അതാണ് mssfix ചോദ്യത്തിലേക്കുള്ള സാധാരണ പ്രവേശനം. ഈ ഓപ്ഷൻ സഹായിച്ചേക്കാം, പക്ഷേ അത് യഥാർത്ഥത്തിൽ വീണ്ടും എഴുതുന്ന TCP കണക്ഷനുകൾക്ക് മാത്രം. അതിന്റെ പരിധി അറിഞ്ഞാൽ ഒരു ക്ലയന്റിനെ രക്ഷിക്കാൻ പ്രവർത്തിക്കുന്ന സെർവർ മാറ്റില്ല.

ഓപ്ഷൻ എന്താണ് വീണ്ടും എഴുതുന്നത്

ടണലിലൂടെ കടന്നുപോകുന്ന TCP ഹാൻഡ്ഷേക്കുകളിൽ പ്രഖ്യാപിക്കുന്ന പരമാവധി സെഗ്മെന്റ് വലുപ്പം mssfix എഡിറ്റ് ചെയ്യുന്നു, അതുവഴി അയയ്ക്കുന്ന വശം എൻകാപ്സുലേറ്റഡ് ബജറ്റിൽ ഒതുങ്ങുന്ന സെഗ്മെന്റുകൾ തിരഞ്ഞെടുക്കുന്നു. അത് ഹാൻഡ്ഷേക്കിൽ പ്രവർത്തിക്കുന്നു, അതായത് മാറ്റത്തിന് മുമ്പ് തുറന്ന കണക്ഷൻ ചർച്ച ചെയ്ത മൂല്യം നിലനിർത്തുന്നു.

അത് UDP ഡാറ്റാഗ്രാമുകൾ ചെറുതാക്കുന്നില്ല, ടണലിന്റെ MTU സജ്ജീകരിക്കുന്നുമില്ല. രണ്ട് വ്യത്യസ്ത പ്രശ്നങ്ങൾ ഒരേ ലക്ഷണം നൽകുന്നു: പാതയുടെ പരിധി അവഗണിക്കുന്ന TCP അയയ്ക്കുന്നയാൾ, ഏത് വലുപ്പത്തിലുമുള്ള വലിയ പാക്കറ്റുകൾ നിശബ്ദമായി ഉപേക്ഷിക്കുന്ന പാത. mssfix ആദ്യത്തേത് കൈകാര്യം ചെയ്യുന്നു, രണ്ടാമത്തേതിന് ഒന്നും ചെയ്യുന്നില്ല.

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

പരിധി ടണലിനുള്ളിലെ TCP ആണ്

TCP ട്രാഫിക് മാത്രമാണ് വീണ്ടും എഴുതുന്നത്. QUIC സെഷൻ, ഗെയിം അല്ലെങ്കിൽ വലിയ UDP ഡാറ്റാഗ്രാമുകൾ അയയ്ക്കുന്ന ആപ്ലിക്കേഷൻ അതിന്റെ സ്വന്തം പാക്കറ്റ് വലുപ്പങ്ങൾ നിലനിർത്തും, ആ കൈമാറ്റങ്ങളാണ് നിലയ്ക്കുന്നതെങ്കിൽ, പരിഹാരം പകരം ടണലിന്റെയോ പാതയുടെയോ MTU-യിൽ ആണ്. TCP ഓപ്ഷനിലേക്ക് നീങ്ങുന്നതിന് മുമ്പ് പരാജയപ്പെടുന്ന കൈമാറ്റം ഏത് പ്രോട്ടോക്കോൾ ഉപയോഗിക്കുന്നുവെന്ന് വായിക്കുക, കാരണം തെറ്റായ ലെയറിന് അതിന്റേതായ പരിഹാരമുണ്ട്.

ദിശയും പ്രധാനമാണ്. ക്ലയന്റ് ക്രമീകരണം ആ ക്ലയന്റ് ടണലിലേക്ക് അയയ്ക്കുന്ന ട്രാഫിക്കിനെ ബാധിക്കുന്നു, അതേസമയം ക്ലയന്റുകളിലേക്ക് കൈമാറുന്ന ഫ്ലോകളെ സെർവർ ഉൾക്കൊള്ളുന്നു. ഇൻബൗണ്ട് ഡൗൺലോഡുകൾ മാത്രം നിലയ്ക്കുകയാണെങ്കിൽ, ക്ലയന്റ് വശത്തെ മൂല്യം മുഴുവൻ കഥയല്ല.

സംഖ്യയും കീവേഡും പോർട്ടബിൾ അല്ല

OpenVPN 2.6 കമ്മ്യൂണിറ്റി പതിപ്പ് മൂല്യത്തിന് ശേഷം ഒരു ഐച്ഛിക കീവേഡ് സ്വീകരിക്കുന്നു. mtu സഹിതം, സംഖ്യ IP, UDP ഹെഡറുകൾ ഉൾപ്പെടെയുള്ള പുറം പാക്കറ്റ് വലുപ്പത്തെ വിവരിക്കുന്നു; അതില്ലാതെ, ആർഗ്യുമെന്റ് മറ്റൊരു കണക്കെടുപ്പ് സമ്പ്രദായം പിന്തുടരുന്നു. അതിനാൽ പതിപ്പുകൾക്കിടയിൽ പകർത്തിയ വരി ഒരേ പാക്കറ്റ് ബജറ്റിനെ വിവരിക്കുന്നില്ല. മറ്റൊരു റിലീസിനുള്ള ട്യൂട്ടോറിയലിന് പകരം നിങ്ങൾ യഥാർത്ഥത്തിൽ പ്രവർത്തിപ്പിക്കുന്ന ബിൽഡിനൊപ്പം വരുന്ന മാനുവൽ പേജ് പരിശോധിക്കുക.

വാക്യഘടന ഇങ്ങനെയാണ്:

mssfix 1400 mtu

1400-നെ നിങ്ങളുടെ പാതയ്ക്കുള്ള ശുപാർശയല്ല, പ്ലേസ്ഹോൾഡർ ആയി കണക്കാക്കുക. അളന്ന പാതയിൽനിന്നും യഥാർത്ഥത്തിൽ ഉപയോഗിക്കുന്ന എൻകാപ്സുലേഷനിൽനിന്നും മൂല്യം കണ്ടെത്തുക, പഴയ പതിപ്പുകളിലെയോ മറ്റ് നടപ്പാക്കലുകളിലെയോ ക്ലയന്റുകൾ കീവേഡ് നിരസിക്കാമെന്നോ വ്യത്യസ്തമായി വ്യാഖ്യാനിക്കാമെന്നോ ഓർക്കുക.

ആദ്യം ഒരു ക്ലയന്റിൽ സ്ഥിരീകരിക്കുക

എന്തെങ്കിലും മാറ്റുന്നതിന് മുമ്പ് പരാജയപ്പെട്ട യന്ത്രത്തിൽനിന്ന് പാത അളക്കുക. ഫ്രാഗ്മെന്റേഷൻ ഇല്ലാതെ പാത വഹിക്കാൻ കഴിയുന്ന പേലോഡാണ് നിങ്ങൾ തിരയുന്ന സംഖ്യ:

ping -M do -s 1472 10.8.0.1
ping -M do -s 1400 10.8.0.1

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

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