VPN MTU കെട്ടുകഥകൾ: നിങ്ങളുടെ പാക്കറ്റുകൾ ചുരുങ്ങുന്നത് എന്തുകൊണ്ട്, ഇടം എവിടെ പോകുന്നു

ആരോ നിങ്ങളോട് VPN "MTU കാരണം പാക്കറ്റ് നഷ്ടപ്പെടുക്കുന്നു" എന്ന് പറയുന്നു, നിങ്ങൾ ടണൽ 1400 ആക്കി വയ്ക്കുന്നു, കൈമാറ്റം വീണ്ടും പ്രവർത്തിക്കുന്നു. ആ ഫലം ഒരു രോഗനിർണയം പോലെ തോന്നുന്നു. സാധാരണയായി ഇത് ഗണിതപരമായ ഒരു യാദൃച്ഛികതയാണ്: നിങ്ങൾ ഒരിക്കലും തിരിച്ചറിയാത്ത ഒരു പരിധിക്ക് താഴെ ഇരിക്കാൻ മതിയായത്ര ചെറിയ ഒരു സംഖ്യ തിരഞ്ഞെടുത്തു, അടുത്ത നെറ്റ്വർക്കിൽ മറ്റൊരു ബജറ്റുമായി അതേ പരിധി വീണ്ടും കാണും.

ഇതിൽ ഭൂരിഭാഗവും രണ്ട് കെട്ടുകഥകൾ സൃഷ്ടിക്കുന്നു. ആദ്യത്തേത് ടണൽ ഇന്റർഫേസിന്റെ MTU പാതയുടെ MTU ആണ് എന്നതാണ്. രണ്ടാമത്തേത് എൻകാപ്സുലേഷന് "ഒരു ഹെഡർ" ചെലവുണ്ട്, PPPoEയ്ക്ക് എണ്ണാൻ യോഗ്യമായ ഒന്നും ചെലവില്ല എന്നതാണ്. നിങ്ങൾ തിരഞ്ഞെടുക്കുന്ന സംഖ്യ യഥാർത്ഥത്തിൽ നിർണ്ണയിക്കപ്പെട്ടതാണെങ്കിലും അത് ഏകപക്ഷീയമായി തോന്നിപ്പിക്കുന്ന വിധത്തിൽ രണ്ടും തെറ്റാണ്.

ആദ്യ കെട്ടുകഥ: ടണലിന്റെ MTU പാതയുടെ MTU

ടണൽ ഇന്റർഫേസിൽ നിങ്ങൾ സജ്ജീകരിക്കുന്ന മൂല്യം, നടപ്പാക്കൽ താഴേക്ക് കൈമാറുന്ന ഏറ്റവും വലിയ ഉൾപ്പാക്കറ്റിനെക്കുറിച്ചുള്ള പ്രാദേശിക വാഗ്ദാനമാണ്. പാതയുടെ യഥാർത്ഥ ശേഷി നിങ്ങൾക്കും ദൂരെയുള്ള അറ്റത്തിനും ഇടയിലുള്ള ഓരോ ലിങ്കിന്റെയും സ്വഭാവമാണ്, റൂട്ട് മാറുമ്പോൾ, മൊബൈൽ കണക്ഷൻ കൈമാറ്റം ചെയ്യുമ്പോൾ അല്ലെങ്കിൽ ട്രാഫിക് മറ്റൊരു പീറിംഗ് എടുക്കുമ്പോൾ അത് മാറാം. സജ്ജീകരിച്ച 1500 നിങ്ങളുടെ ഹോസ്റ്റ് എന്ത് നിർമ്മിക്കും എന്ന് പറയുന്നു, നെറ്റ്വർക്ക് എന്ത് വഹിക്കും എന്നല്ല.

പാത-MTU കണ്ടെത്തൽ ഈ രണ്ടിനെയും യോജിപ്പിക്കാൻ ഉള്ളതാണ്, അത് പ്രതികരണത്തെ ആശ്രയിക്കുന്നു. IPv4-ൽ പൂർണ്ണ വലിപ്പമുള്ള പാക്കറ്റ് കൈമാറാൻ കഴിയാത്ത റൂട്ടർ ICMP "fragmentation needed" സന്ദേശം അയയ്ക്കണം, അയയ്ക്കുന്നയാൾ തന്റെ കണക്ക് കുറയ്ക്കുന്നു. IPv6-ൽ തത്തുല്യമായത് Packet Too Big സന്ദേശമാണ്, റൂട്ടറുകൾ ട്രാൻസിറ്റിൽ ഫ്രാഗ്മെന്റ് ചെയ്യുന്നേയില്ല. ആ പ്രതികരണം ഫിൽട്ടർ ചെയ്യപ്പെട്ടാൽ, അയയ്ക്കുന്നയാൾ പാത വഹിക്കാൻ കഴിയാത്ത പാക്കറ്റുകൾ നിർമ്മിച്ചുകൊണ്ടിരിക്കും, എന്തുകൊണ്ടെന്ന് ഒന്നും അദ്ദേഹത്തോട് പറയുന്നുമില്ല.

രണ്ടാം കെട്ടുകഥ: എൻകാപ്സുലേഷന് ഒരു ഹെഡർ ചെലവ്

പുറം പാളികൾ സത്യസന്ധമായി എണ്ണുക. പുറം IP ഹെഡർ IPv4-ൽ 20 ബൈറ്റ് അല്ലെങ്കിൽ IPv6-ൽ 40. NAT കടക്കാൻ UDP എൻകാപ്സുലേഷൻ 8 ചേർക്കുന്നു. ടണൽ പ്രോട്ടോക്കോൾ സ്വന്തം ഹെഡർ, ഇനീഷ്യലൈസേഷൻ വെക്ടർ അല്ലെങ്കിൽ നോൺസ്, സൈഫറിന്റെ ബ്ലോക്ക് അല്ലെങ്കിൽ വിന്യാസ പരിധി വരെ പാഡിംഗ്, ട്രെയിലർ, സമഗ്രതാ പരിശോധനാ മൂല്യം എന്നിവ ചേർക്കുന്നു. പ്രോട്ടോക്കോളും സൈഫറും അനുസരിച്ച്, ഉൾപ്പാക്കറ്റ് തുടങ്ങുന്നതിന് മുൻപ് തന്നെ ആകെ തുക സുഖമായി പത്തുകൾ ബൈറ്റുകളിൽ എത്തുന്നു.

പിന്നീട് ഉൾപ്പാക്കറ്റിന്റെ സ്വന്തം ഹെഡറുകൾക്കായി വീണ്ടും കുറയ്ക്കുക. ടണലിനുള്ളിലെ TCP സെഗ്മെന്റ് സ്വന്തം 20 ബൈറ്റ് IP ഹെഡറും 20 ബൈറ്റ് TCP ഹെഡറും വഹിക്കുന്നു, TCP-യുടെ MSS MTU-വിൽ നിന്നാണ് വരുന്നത്, ടണലിന്റെ നാമമാത്ര പേലോഡിൽ നിന്നല്ല. അതുകൊണ്ടാണ് ping ചെറിയ പേലോഡോടെ വിജയിക്കുമ്പോൾ ഫയൽ കൈമാറ്റം നിലയ്ക്കുന്നത്: ഉപകരണങ്ങൾ വ്യത്യസ്ത കാര്യങ്ങൾ പരിശോധിക്കുന്നു, അവയിൽ ഒന്ന് മാത്രം പൂർണ്ണ വലിപ്പമുള്ള TCP സെഗ്മെന്റ് പ്രയോഗിക്കുന്നു.

ip link show tun0
ping -M do -s 1472 192.0.2.10
ping -M do -s 1400 192.0.2.10

ആദ്യ കമാൻഡ് സജ്ജീകരിച്ച ടണൽ MTU റിപ്പോർട്ട് ചെയ്യുന്നു. രണ്ട് പ്രോബുകളും 1472 ബൈറ്റ് പേലോഡ് അയയ്ക്കുന്നു, അത് IPv4, ICMP ഹെഡറുകളുടെ 28 ബൈറ്റുകളോടെ 1500 ബൈറ്റ് പാക്കറ്റാണ്, പിന്നെ ചെറിയത്. വലിയ പ്രോബ് പൂർണ്ണമായി പരാജയപ്പെട്ട് ചെറിയത് വിജയിച്ചാൽ, നിങ്ങൾക്ക് വലിപ്പാധിഷ്ഠിതമായ ഒരു തകരാറുണ്ട്, പൊതുവായ റൂട്ടിംഗ് പ്രശ്നമല്ല.

മൂന്നാം കെട്ടുകഥ: PPPoE ഇപ്പോഴും നിങ്ങൾക്ക് വ്യക്തമായ 1500 നൽകുന്നു

പരമ്പരാഗത PPPoE ആക്സസ് ലിങ്ക് 1500 ബൈറ്റ് IP പാക്കറ്റ് വഹിക്കുന്നില്ല. PPPoE ഹെഡറും PPP പ്രോട്ടോക്കോൾ ഫീൽഡും ഈതർനെറ്റ് ഫ്രെയിമിനുള്ളിൽ 8 ബൈറ്റ് എടുക്കുന്നു, ഇത് IP പാക്കറ്റിന് 1492 നൽകുന്നു. RFC 2516-ൽ വിവരിച്ച പരമ്പരാഗത പരിധിയാണിത്. അത്തരം ലിങ്കിലൂടെ VPN ഓടിച്ചാൽ, ടണലിന്റെ അധികച്ചെലവ് 1500-ൽ നിന്നല്ല, ആ 1492-ൽ നിന്നാണ് വരുന്നത്.

RFC 4638 ആക്സസ് കോൺസന്ട്രേറ്ററും ഉപഭോക്തൃ ഉപകരണവും പിന്തുണയ്ക്കുമ്പോൾ വലിയ PPP പേലോഡിനെക്കുറിച്ച് ചർച്ച ചെയ്യാനുള്ള വഴി നിർവചിക്കുന്നു, അതുകൊണ്ടാണ് "ഈ കണക്ഷൻ PPPoE ഉപയോഗിക്കുന്നു" എന്നത് മാത്രം ഒരു പ്രത്യേക സംഖ്യ തെളിയിക്കാത്തത്. പ്രാദേശിക ക്രമീകരണത്തിന് ഇടയ്ക്കുള്ള ഉപകരണം ഒരിക്കലും കോൺഫിഗർ ചെയ്യാത്ത ഒരു പാക്കറ്റ് സ്വീകരിക്കാൻ നിർബന്ധിക്കാനാവില്ല, അതിനാൽ ഉപയോഗപ്രദമായ ചോദ്യം ലേബൽ എന്ത് പറയുന്നു എന്നല്ല, ലിങ്ക് യഥാർത്ഥത്തിൽ എന്തിൽ യോജിച്ചു എന്നതാണ്.

പരാജയം എന്തുകൊണ്ട് തിരഞ്ഞെടുക്കപ്പെട്ടതായി തോന്നുന്നു

ചെറിയ അഭ്യർത്ഥനകൾ വിജയിക്കുന്നതും വലിയ കൈമാറ്റങ്ങൾ നിലയ്ക്കുന്നതും പാത-MTU കറുത്ത ദ്വാരത്തിന്റെ പരമ്പരാഗത ലക്ഷണമാണ്. ഹാൻഡ്ഷേക്ക്, DNS ചോദ്യം, API കോൾ എന്നിവയെല്ലാം ഒതുങ്ങുന്നു; കൂട്ട കൈമാറ്റം ഒരു ലിങ്കിൽ ചാകുന്ന പൂർണ്ണ വലിപ്പ സെഗ്മെന്റുകൾ സൃഷ്ടിക്കുന്നു, പ്രശ്നം റിപ്പോർട്ട് ചെയ്യേണ്ടിയിരുന്ന ICMP സന്ദേശം ഒരിക്കലും എത്തുന്നുമില്ല. കണക്ഷൻ കുഴപ്പമില്ലാത്തതായി തോന്നുന്നു, ഡൗൺലോഡ് തൂങ്ങുന്നു, ഇത് ആളുകളെ പാതയ്ക്ക് പകരം സർവറിലേക്ക് നോക്കാൻ അയയ്ക്കുന്നു.

രണ്ടാമത്തെ, ബന്ധപ്പെട്ട തെറ്റ് മൂന്ന് സംഖ്യകൾ കൂട്ടിക്കുഴയ്ക്കുന്നതാണ്: ഇന്റർഫേസ് MTU, TCP MSS, പ്രോട്ടോക്കോളിന്റെ സ്വന്തം ഫ്രാഗ്മെന്റേഷൻ അല്ലെങ്കിൽ പാഡിംഗ് ക്രമീകരണം. റൂട്ടറിലെ MSS ക്ലാമ്പിംഗ് പ്രഖ്യാപിത MSS മാറ്റിയെഴുതുന്നു, അതുവഴി അയയ്ക്കുന്നയാൾ ചെറിയ സെഗ്മെന്റുകൾ നിർമ്മിക്കുന്നു; അത് ടണൽ MTU മാറ്റുന്നില്ല, UDP ട്രാഫിക്കിന് സഹായിക്കുന്നുമില്ല. ബന്ധപ്പെട്ടതായി തോന്നുന്നതുകൊണ്ട് മൂന്നിനും ഒരേ സംഖ്യ നൽകുന്നതാണ് നല്ല ഉദ്ദേശ്യത്തോടെയുള്ള ഒരു മാറ്റം പ്രവർത്തിക്കുന്ന ക്രമീകരണം തകർക്കുന്ന വഴി.

എന്ത് മാറ്റണം, ഏത് ക്രമത്തിൽ

തെളിവിൽ തുടങ്ങുക. മുകളിലെ പ്രോബുകളിലൂടെ തകരാർ വലിപ്പാധിഷ്ഠിതമാണെന്ന് ഉറപ്പാക്കുക, എന്നിട്ട് കടന്നുപോകുന്ന ഏറ്റവും ചെറിയ വലിപ്പവും പരാജയപ്പെടുന്ന ഏറ്റവും വലിയ വലിപ്പവും കണ്ടെത്തുക. ടണലിനെ കുറ്റപ്പെടുത്തുന്നതിന് മുൻപ് ആക്സസ് ലിങ്കിന്റെ യഥാർത്ഥ MTU പരിശോധിക്കുക; PPPoE ലിങ്ക് നിങ്ങളുടെ VPN അതിൽ തൊടുന്നതിന് മുൻപ് തന്നെ ബജറ്റ് പരിമിതപ്പെടുത്തുന്നു. മാറ്റം പിൻവലിക്കാനാകാൻ യഥാർത്ഥ മൂല്യങ്ങൾ കുറിച്ചുവയ്ക്കുക.

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