PPPoE-യിലെ OpenVPN: link-mtu, tun-mtu അതോ mssfix കുറയ്ക്കണോ?

പിംഗ് മറുപടി നൽകുന്നു, DNS പരിഹരിക്കുന്നു, പൂർണ്ണ വലിപ്പമുള്ള സെഗ്മെന്റ് ആവശ്യമുള്ള ഓരോ പേജും കുടുങ്ങുന്നു. സ്വന്തം കാപ്സ്യുലേഷൻ ചേർക്കുന്ന ലിങ്കിൽ, വഴി നിശ്ശബ്ദമായി കുറച്ച് ഡസൻ ബൈറ്റ് ബജറ്റ് നഷ്ടപ്പെടുത്തുന്നു, വൃത്തിയുള്ള Ethernet-നായി എഴുതിയ പ്രൊഫൈൽ ലൈനിന് വഹിക്കാനാകാത്ത പാക്കറ്റുകൾ ആവശ്യപ്പെട്ടുകൊണ്ടിരിക്കുന്നു. കണക്ഷൻ മന്ദഗതിയിലല്ല; പ്രധാനമായ പാക്കറ്റുകൾ കൃത്യമായി വലിച്ചെറിയുകയാണ്.

മൂന്ന് ഓപ്ഷനുകൾക്ക് ഇത് പരിഹരിക്കാം, അവ വ്യത്യസ്ത പാളികളിൽ പ്രവർത്തിക്കുന്നു. തെറ്റായത് തിരഞ്ഞെടുത്താൽ ഒന്നും സംഭവിക്കില്ല അല്ലെങ്കിൽ ടണൽ പുതിയ രീതിയിൽ ദുർബലമാകും, അതിനാൽ തിരഞ്ഞെടുപ്പ് വഴി യഥാർത്ഥത്തിൽ എന്തിനെ പിന്തുണയ്ക്കുന്നു എന്നതിൽ നിന്നാണ് തുടങ്ങുന്നത്.

മൂന്ന് നോബുകൾ, മൂന്ന് വ്യത്യസ്ത പാളികൾ

link-mtu പുറം ബജറ്റാണ്: എൻക്രിപ്റ്റ് ചെയ്ത പേലോഡിനൊപ്പം OpenVPN ഹെഡർ, UDP ഹെഡർ, പുറം IP ഹെഡർ. മെഷീനിൽ നിന്ന് എന്ത് പുറത്തുപോകുന്നു എന്ന് ഇത് വിവരിക്കുന്നു, അതിനാൽ ഭൗതിക വഴി പരിമിതപ്പെടുത്തുന്ന സംഖ്യ ഇതാണ്.

tun-mtu ആന്തരിക ബജറ്റാണ്: നിങ്ങളുടെ ട്രാഫിക് കാണുന്ന ഇന്റർഫേസ്. വഴിക്ക് വഹിക്കാവുന്നതിനേക്കാൾ ടണലിന്റെ ഓവർഹെഡ് കൃത്യമായി കൂടുതലാണ് ഇത്, OpenVPN സാധാരണയായി നിങ്ങളെ സെറ്റ് ചെയ്യാൻ നിർബന്ധിക്കുന്നതിനുപകരം ഇത് കണക്കാക്കുന്നു.

mssfix തികച്ചും വേറെ സംവിധാനമാണ്. TCP ഹാൻഡ്ഷേക്കുകളിൽ പ്രഖ്യാപിക്കുന്ന പരമാവധി സെഗ്മെന്റ് വലിപ്പം ഇത് മാറ്റിയെഴുതുന്നു, അതുവഴി TCP പങ്കാളികൾ കാപ്സ്യുലേഷനുശേഷം ഇടംപിടിക്കുന്ന സെഗ്മെന്റുകൾ തിരഞ്ഞെടുക്കും. ഇത് ഇന്റർഫേസിന്റെ MTU മാറ്റുന്നില്ല, UDP-യിൽ യാതൊരു ഫലവുമില്ല.

നിങ്ങൾ link-mtu വ്യക്തമായി സെറ്റ് ചെയ്താൽ, ആന്തരിക MTU കണക്കാക്കാൻ OpenVPN അതിന്റെ സ്വന്തം ഓവർഹെഡ് കുറയ്ക്കുന്നു. ആ ഓവർഹെഡ് സ്ഥിരമായ ഒരു സ്ഥിരാങ്കമല്ല; അത് സൈഫറിനെയും പ്രാമാണീകരണത്തെയും ആശ്രയിച്ചിരിക്കുന്നു, അതുകൊണ്ടാണ് ഫോറത്തിൽ നിന്ന് പകർത്തിയ മൂല്യം മറ്റൊരു പ്രൊഫൈലിൽ തെറ്റായിരിക്കാം. link-mtu ഉം tun-mtu ഉം ഒരുമിച്ച് സെറ്റ് ചെയ്താൽ ക്ലയന്റിന് വിരുദ്ധമായ രണ്ട് നിർദ്ദേശങ്ങൾ നൽകും.

ഏതെങ്കിലും സംഖ്യ തിരഞ്ഞെടുക്കുന്നതിന് മുമ്പ് വഴി അളക്കുക

ടണലിനുള്ളിൽ നിന്നല്ല, ഭൗതിക ഇന്റർഫേസിൽ നിന്ന് അളക്കുക, പിംഗ് പേലോഡ് റിപ്പോർട്ട് ചെയ്യുന്നു, പാക്കറ്റ് വലിപ്പമല്ല എന്ന് ഓർക്കുക. പേലോഡിനെ 1500 ബൈറ്റ് ഫ്രെയിമുമായി താരതമ്യപ്പെടുത്തുന്നതിന് മുമ്പ് IPv4, ICMP ഹെഡറുകൾക്ക് 28 ബൈറ്റ് ചേർക്കുക, പങ്കാളി മറ്റൊരു സംഖ്യ റിപ്പോർട്ട് ചെയ്യുമ്പോൾ ആ തിരുത്ത് ഓർമ്മയിൽ സൂക്ഷിക്കുക.

Linux ക്ലയന്റിൽ ping -M do -s 1472 ഫ്രാഗ്മെന്റേഷൻ വിലക്കുന്നു, പാക്കറ്റ് വളരെ വലുതാണെങ്കിൽ പരാജയപ്പെടുന്നു. കടന്നുപോകുന്നതുവരെ പേലോഡ് കുറയ്ക്കുക, തുടർന്ന് വഴിയുടെ MTU ലഭിക്കാൻ 28 ചേർക്കുക. PPPoE 8 ബൈറ്റ് ചെലവാക്കുന്നു, അതിനാൽ DSL-ൽ 1492 സാധാരണമാണ്. DS-Lite-ഉം ചില മൊബൈൽ വഴികളും 40 അല്ലെങ്കിൽ കൂടുതൽ ചെലവാക്കുന്നു, ഉത്തരം സാധാരണയായി നാമമാത്ര ലിങ്ക് വേഗത സൂചിപ്പിക്കുന്നതിനേക്കാൾ താഴെയായിരിക്കും.

എല്ലാ പിംഗ് വലിപ്പവും വിജയിക്കുന്നു, പക്ഷേ വലിയ കൈമാറ്റങ്ങൾ ഇപ്പോഴും കുടുങ്ങുന്നു എങ്കിൽ ലളിതമായ വലിപ്പപരിധിയല്ല, കറുത്ത കുഴിയാണ് സംശയിക്കേണ്ടത്. ആവശ്യമായ ഫ്രാഗ്മെന്റേഷനെക്കുറിച്ചുള്ള ICMP സന്ദേശം വഴിയിൽ എവിടെയോ ഫിൽട്ടർ ചെയ്യപ്പെടുന്നു, അതിനാൽ അയയ്ക്കുന്നയാൾ ഒരിക്കലും ചെറുതാക്കാൻ പഠിക്കുന്നില്ല, വലിയ സെഗ്മെന്റ് ആവശ്യമുള്ള ഫ്ലോകൾ മാത്രമാണ് അത് ശ്രദ്ധിക്കുന്നത്.

ആദ്യം TCP പരിമിതപ്പെടുത്തുക, പിന്നീട് ടണൽ ചുരുക്കുക

TCP ഹാൻഡ്ഷേക്കുകൾ മാത്രമാണ് mssfix സ്പർശിക്കുന്നത്, അതിനാൽ ആദ്യം പരീക്ഷിക്കാൻ ഏറ്റവും കുറഞ്ഞ ഇടപെടലുള്ള നിയന്ത്രണമായി ഇത് മാറുന്നു. വഴിയുടെ യഥാർത്ഥ ബജറ്റിന് അൽപ്പം താഴെ ഇത് സെറ്റ് ചെയ്യുക, രണ്ട് അറ്റങ്ങളും യോജിക്കാൻ സെർവറിൽ നിന്ന് അതേ മൂല്യം അയയ്ക്കുക, വലിയ ഡൗൺലോഡ് വീണ്ടും പരിശോധിക്കുക. കുടുക്കം മാറിയാൽ പ്രശ്നം TCP സെഗ്മെന്റ് വലിപ്പമായിരുന്നു, മറ്റൊന്നും മാറ്റേണ്ടതില്ല.

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

പഴയ ഫ്രാഗ്മെന്റേഷൻ ഓപ്ഷനിലേക്ക് നീങ്ങരുത്. അത് ടണലിനുള്ളിൽ പാക്കറ്റുകൾ വിഭജിച്ചു, ഓവർഹെഡ് കൂട്ടി, നല്ല കാരണങ്ങളാൽ ഒഴിവാക്കപ്പെട്ടു; ആധുനിക OpenVPN വഴി കൃത്യമായി വിവരിക്കാൻ പ്രതീക്ഷിക്കുന്നു.

ചെറിയ പരിശോധനകൾ എന്തുകൊണ്ട് പ്രവർത്തിക്കുന്നു

DNS ക്വറികൾ, ICMP എക്കോകൾ, TCP ഹാൻഡ്ഷേക്കുകൾ എന്നിവയെല്ലാം പരാജയപ്പെടുന്ന വലിപ്പത്തിന് വളരെ താഴെയാണ്. അതിനാൽ ടണൽ എല്ലാ വേഗ പരിശോധനയിലും ആരോഗ്യകരമായി കാണപ്പെടുന്നു, അതേസമയം TLS ഹാൻഡ്ഷേക്കുകളും HTTP പ്രതികരണങ്ങളും നിശ്ശബ്ദമായി പരാജയപ്പെടുന്നു. പ്രവർത്തിക്കുന്ന traceroute-ഉം ആദ്യ വലിയ പ്രതികരണത്തിൽ കുടുങ്ങുന്ന ബ്രൗസറും എന്ന ആ കോമ്പിനേഷനാണ് തിരയേണ്ട അടയാളം. പുതിയ പ്രൊഫൈലിലേക്ക് നീങ്ങുന്നതിന് മുമ്പ് പൂർണ്ണ വലിപ്പത്തിലുള്ള പരിശോധനയിലേക്ക് നീങ്ങുക.

പരാജയപ്പെട്ട ട്രാഫിക് ഉപയോഗിച്ച് പരിശോധിക്കുക. വലിയ പേജ് നേടുക, ബാധിത സേവനം അതാണെങ്കിൽ പൂർണ്ണ വലിപ്പത്തിലുള്ള UDP ഡാറ്റാഗ്രാം അയയ്ക്കുക, മറ്റൊരു ലിങ്കിലെ രണ്ടാമത്തെ ക്ലയന്റിൽ നിന്ന് ആവർത്തിക്കുക. അളന്ന വഴി MTU-യും നിങ്ങൾ തിരഞ്ഞെടുത്ത മൂല്യവും രേഖപ്പെടുത്തുക, അല്ലാത്തപക്ഷം പ്രൊഫൈൽ സ്പർശിക്കുന്ന അടുത്ത വ്യക്തി ആ സംഖ്യയെ ഏകപക്ഷീയമായി കണക്കാക്കും.

IPv6 ടണലിലൂടെ പോകുമ്പോൾ ആന്തരിക MTU 1280-ൽ താഴെ ഒരിക്കലും കൊണ്ടുവരരുത്, കാരണം ഓരോ IPv6 ലിങ്കും വഹിക്കേണ്ട ഏറ്റവും കുറഞ്ഞ അളവ് അതാണ്. ചെറിയ MTU വഴിയെക്കുറിച്ചുള്ള വസ്തുതയാണ്, വികാരം കൊണ്ട് ക്രമീകരിക്കുന്ന പ്രകടന ക്രമീകരണമല്ല.