VPN വഴിയുള്ള പാത്ത് MTU കണ്ടെത്തൽ: വലിപ്പവും ICMP വിടവും

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

പാത്ത് MTU യഥാർത്ഥത്തിൽ എന്താണ് അളക്കുന്നത്

പാത്ത് MTU രണ്ട് ഹോസ്റ്റുകൾക്കിടയിലുള്ള പാതയിലെ ഏറ്റവും ചെറിയ കണ്ണി MTU ആണ്, നിങ്ങളുടെ പ്രാദേശിക ഇന്റർഫേസിൽ അച്ചടിച്ചിരിക്കുന്ന MTU അല്ല. പ്രാദേശിക മൂല്യം ഏകദേശ കണക്ക് ആരംഭിക്കുന്ന ബിന്ദുവാണ്, അത് എവിടെ അവസാനിക്കണം എന്ന് പാത തീരുമാനിക്കുന്നു. അതുകൊണ്ടാണ് ഒരേപോലുള്ള ടണൽ ഒരു ആക്സസ് നെറ്റ്വർക്കിൽ പ്രവർത്തിച്ച് മറ്റൊന്നിൽ നിലയ്ക്കുന്നത്: പാത മാറി, കോൺഫിഗറേഷൻ അല്ല. ഒരിക്കൽ അളന്ന് എല്ലായിടത്തും അനുമാനിക്കുന്നതാണ് ഈ പ്രശ്നത്തെ ജീവനോടെ നിർത്തുന്ന തെറ്റ്.

ഒരു ടണലിന് പ്രധാനമായ സംഖ്യ ആന്തരിക MTU ആണ്, അതായത് പുറം പാതയുടെ അനുവാദത്തിൽ നിന്ന് എൻക്യാപ്സുലേഷൻ ഉപയോഗിക്കുന്നത് കുറച്ചത്. WireGuard ഒരു പുറം IP ഹെഡറും UDP ഹെഡറും ചേർക്കുന്നു; മറ്റ് ട്രാൻസ്പോർട്ടുകൾ സ്വന്തമായവ ചേർക്കുന്നു. ആന്തരിക വലിപ്പം വളരെ ഉയർത്തിയാൽ പൂർണ്ണ വലിപ്പമുള്ള ഓരോ പാക്കറ്റിനും ഒരിക്കലും സംഭവിക്കാത്ത ഫ്രാഗ്മെന്റേഷൻ ആവശ്യമാകും.

ടണൽ ഉപയോഗയോഗ്യമായ പാക്കറ്റ് ചെറുതാക്കുന്നത് എന്തുകൊണ്ട്

ടണൽ ഇന്റർഫേസ് ഭൗതിക കണ്ണിയുടെ MTU നിലനിർത്തുന്നുവെങ്കിൽ, ഓരോ വലിയ പാക്കറ്റും താഴെ ആരെങ്കിലും അത് ഫ്രാഗ്മെന്റ് ചെയ്യാൻ തയ്യാറാകുന്നതിനെ ആശ്രയിക്കുന്നു. IPv4 തത്വത്തിൽ അത് അനുവദിക്കുന്നു, പക്ഷേ ഫ്രാഗ്മെന്റ് ചെയ്യരുതെന്ന് പറഞ്ഞ റൗട്ടർ പകരം ഒരു പിശക് തിരികെ നൽകുന്നു. IPv6 റൗട്ടറുകൾ ട്രാൻസിറ്റിൽ ഒരിക്കലും ഫ്രാഗ്മെന്റ് ചെയ്യുന്നില്ല, അതിനാൽ അതേ ക്രമീകരണം വിലാസ കുടുംബമനുസരിച്ച് വ്യത്യസ്തമായി പെരുമാറുന്നു. ഏതായാലും എന്തെങ്കിലും തിരികെ റിപ്പോർട്ട് ചെയ്യുന്നതുവരെ അയച്ചയാൾ ഒന്നും പഠിക്കുന്നില്ല.

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

ഫീഡ്ബാക്ക് എത്തുമ്പോൾ മാത്രമേ കണ്ടെത്തൽ പ്രവർത്തിക്കൂ

IPv4 കണ്ടെത്തൽ don't-fragment ബിറ്റിനെ ആശ്രയിക്കുന്നു: പാക്കറ്റ് മുന്നോട്ട് അയക്കാനാകാത്ത റൗട്ടർ അടുത്ത ഹോപ്പിന്റെ MTU-യോടെ ICMP fragmentation-needed തിരികെ നൽകുന്നു, അയച്ചയാൾ തന്റെ ഏകദേശ കണക്ക് കുറയ്ക്കുന്നു. IPv6 പകരം Packet Too Big സന്ദേശങ്ങൾ ഉപയോഗിക്കുന്നു, കാരണം റൗട്ടറുകൾ ട്രാൻസിറ്റിൽ ഫ്രാഗ്മെന്റ് ചെയ്യുന്നില്ല. രണ്ട് സംവിധാനങ്ങളും സന്ദേശം ടണലിലൂടെയും മടക്കപ്പാതയിലെ ഏത് ഫയർവാളിനും അപ്പുറത്തൂടെയും അയച്ചയാളിലേക്ക് തിരികെയുള്ള വഴി കണ്ടെത്തുമെന്ന് അനുമാനിക്കുന്നു. ആ അനുമാനം പരാജയപ്പെടുമ്പോൾ, പാത വഹിക്കാനാകാത്ത ഒരു വലിപ്പം അയച്ചയാൾ വീണ്ടും വീണ്ടും ശ്രമിക്കുന്നു.

echo request-ഉം echo reply-യും അനുവദിക്കുന്ന ഒരു ഫയർവാൾ ആ പിശക് തരങ്ങൾ അനുവദിച്ചിരിക്കണമെന്നില്ല. ICMP ഒരു കുടുംബമാണ്, കൂടാതെ ഇവിടെ പ്രധാനമായ അംഗങ്ങൾ പിശകുകളാണ്, എക്കോ ജോടിയല്ല. ടണലിന്റെ ഇരു അറ്റങ്ങളിലും അവയ്ക്കിടയിലുള്ള പാതയിലും നിയന്ത്രണ ട്രാഫിക് നയം പരിശോധിക്കുക, എല്ലായിടത്തും എല്ലാ ICMP തരങ്ങളും അനുവദിക്കുന്നതിനുപകരം പ്ലാറ്റ്ഫോമിന്റെ പിന്തുണയുള്ള മാർഗ്ഗനിർദ്ദേശം പിന്തുടരുക.

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

സംഖ്യ ഊഹിക്കുന്നതിനുപകരം പാത പരിശോധിക്കുക

ലക്ഷ്യസ്ഥാനം, ആക്സസ് നെറ്റ്വർക്ക്, ടണൽ എന്നിവ സ്ഥിരമായി നിർത്തി പാക്കറ്റ് വലിപ്പം മാത്രം മാറ്റുക. MTU സൂചനയോടെ പരാജയപ്പെടുന്ന don't-fragment പരിശോധന അടുത്ത ഹോപ്പിന്റെ പരിധി നൽകുന്നു; ഏതെങ്കിലും വലിപ്പം കടക്കുന്നതുവരെ ആവർത്തിക്കുക, വലിപ്പവും വിലാസ കുടുംബവും രേഖപ്പെടുത്തുക.

ping -M do -s 1400 10.60.20.10
ping -M do -s 1300 10.60.20.10
ping -6 -M do -s 1300 2001:db8::10

ഒതുങ്ങുന്ന ഒരു പിംഗ് യഥാർത്ഥ അപ്ലിക്കേഷന്റെ പൂർണ്ണ വലിപ്പ സെഗ്മെന്റുകൾ ഒതുങ്ങുമെന്ന് തെളിയിക്കുന്നില്ല, അതിനാൽ യഥാർത്ഥത്തിൽ പരാജയപ്പെട്ട കൈമാറ്റത്തോടെ പരിശോധന ആവർത്തിക്കുക. ഏറ്റവും വലിയ വിജയിച്ച പരിശോധനയെ നിങ്ങൾ കോൺഫിഗർ ചെയ്ത ടണൽ MTU-യുമായി താരതമ്യം ചെയ്യുക, രണ്ട് സംഖ്യകളും നിങ്ങളുടെ കുറിപ്പുകളിൽ വെവ്വേറെ സൂക്ഷിക്കുക. അവ ഏകദേശം ഒരു ഹെഡറിന്റെ അളവിൽ വ്യത്യാസപ്പെട്ടാൽ, നിങ്ങൾ കണ്ടെത്തിയത് ഒരു തകരാറല്ല, എൻക്യാപ്സുലേഷൻ ഓവർഹെഡ് ആണ്.

RFC 4821-ൽ വിവരിച്ചിരിക്കുന്ന PLPMTUD മുകളിലേക്ക് പരിശോധിക്കുന്നു, എത്തിച്ചേർന്ന പിശകുകളെ വിശ്വസിക്കുന്നതിനുപകരം ട്രാൻസ്പോർട്ട് അംഗീകാരങ്ങൾ ഉപയോഗിക്കുന്നു. ICMP ഫിൽട്ടർ ചെയ്യുന്ന പാതകളിൽ ഇത് സഹായിക്കുന്നു, പക്ഷേ പിന്തുണ സ്റ്റാക്കിനും അപ്ലിക്കേഷനും അനുസരിച്ച് വ്യത്യാസപ്പെടുന്നു. TCP ഫ്ലോ സ്വയം കരകയറിയേക്കാം, സ്ഥിരമായ ഡാറ്റാഗ്രാം വലിപ്പമുള്ള UDP അപ്ലിക്കേഷൻ പരാജയപ്പെട്ടുകൊണ്ടിരിക്കുമ്പോൾ.

ഒരു മൂല്യം തിരഞ്ഞെടുത്ത് ന്യായീകരണം രേഖപ്പെടുത്തുക

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

IPv4 സംവിധാനം RFC 1191-ൽ വിവരിച്ചിരിക്കുന്നു, IPv6 പാക്കറ്റൈസേഷൻ മാർഗ്ഗനിർദ്ദേശം RFC 8201-ൽ; രണ്ടും പേരിടുന്നത് അടുത്ത എൻജിനീയർക്ക് അനുമാനം വീണ്ടും നിർദ്ധാരണം ചെയ്യേണ്ടതില്ലാതാക്കുന്നു. നിങ്ങൾ തിരഞ്ഞെടുത്ത വലിപ്പത്തിൽ കൈമാറ്റം ഇപ്പോഴും നിലയ്ക്കുന്നുവെങ്കിൽ, സംഖ്യ കുറയ്ക്കുന്നത് നിർത്തി അടുത്ത പാളി നോക്കുക. എല്ലാ വലിപ്പത്തിലും പരാജയപ്പെടുന്ന പാത MTU പ്രശ്നമല്ല.