MTU കറുത്ത കുഴി: ചെറിയ അഭ്യർത്ഥനകൾ എന്തുകൊണ്ട് പ്രവർത്തിക്കുന്നു, എന്നാൽ അപ്ലോഡുകൾ നിലയ്ക്കുന്നു

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

കുഴിയെ കറുപ്പാക്കുന്നത് എന്ത്

ഓരോ ലിങ്കിനും പരമാവധി സംപ്രേഷണ യൂണിറ്റ് ഉണ്ട്, അടുത്ത ഹോപ്പിന്റെ പരിധിയേക്കാൾ വലിയ പാക്കറ്റ് ഒന്നുകിൽ ശകലീകരിക്കണം, അല്ലെങ്കിൽ അതു പറയുന്ന ICMP സന്ദേശത്തോടെ നിരസിക്കണം. പാത MTU കണ്ടെത്തൽ ആ സന്ദേശം എത്തുന്നതിനെയും അത് മാനിക്കപ്പെടുന്നതിനെയും ആശ്രയിച്ചിരിക്കുന്നു. അത് ഫിൽട്ടർ ചെയ്യുകയോ അവഗണിക്കുകയോ ചെയ്താൽ ഒരിക്കലും ഒതുങ്ങാത്ത പാക്കറ്റ് അയച്ചയാൾ വീണ്ടും വീണ്ടും അയക്കും.

എൻകാപ്സുലേഷൻ ഇത് VPN-ന് ചുറ്റും സാധാരണമാക്കുന്നു, കാരണം ടണൽ ഇതിനകം ഭൗതിക ലിങ്കിനായി അളന്ന പാക്കറ്റിന് പുറം ഹെഡർ ചേർക്കുന്നു. ഉള്ളിലെ പാക്കറ്റ് 1500 ബൈറ്റിൽ നിയമപരമാണ്, എൻകാപ്സുലേറ്റ് ചെയ്തത് അല്ല, അതിനാൽ അത് അതിർത്തിയിൽ മരിക്കുന്നു, ചെറിയ പാക്കറ്റുകൾ കടന്നുപോകുന്നു. പൂർത്തിയായ ഹാൻഡ്ഷേക്കും പ്രവർത്തിക്കുന്ന ലോഗിൻ പേജും ചെറിയ പാക്കറ്റുകൾ പ്രവർത്തിക്കുന്നു എന്ന് മാത്രം തെളിയിക്കുന്നു. അപ്ലിക്കേഷൻ അയക്കാൻ ശ്രമിക്കുന്ന ഏറ്റവും വലിയ പാക്കറ്റാണ് പ്രധാനം.

അത് പൊട്ടുന്ന വലിപ്പം കണ്ടെത്തുക

ശകലീകരിക്കാത്ത പരിശോധന ഉപയോഗിച്ച് പേലോഡിന്റെ വലിപ്പം ദ്വിമാന തിരയൽ ചെയ്യുക, ടണലിന്റെ ഒരു വശത്തെ ഹോസ്റ്റിൽ നിന്ന് മറുവശത്തെ ഹോസ്റ്റിലേക്ക്. വിജയിക്കുന്ന ഏറ്റവും വലിയ പേലോഡ് നിങ്ങളുടെ ഉപയോഗയോഗ്യമായ പാത MTU-യിൽ നിന്ന് ഹെഡർ ഓവർഹെഡ് കുറച്ചതാണ്.

ping -M do -s 1400 -c 2 192.0.2.20
ping -M do -s 1200 -c 2 192.0.2.20
ping -f -l 1372 192.0.2.20

1472 ബൈറ്റിന്റെ പേലോഡ് വൃത്തിയായ 1500 ബൈറ്റ് Ethernet പാതയിൽ വിജയിക്കുന്നു, IPv4, ICMP ഹെഡറുകളുടെ 28 ബൈറ്റ് ചേർക്കുമ്പോൾ. ടണൽ ഉയർന്നതിന് ശേഷം അതേ പരിശോധന ചെറിയ പേലോഡിൽ മാത്രം വിജയിക്കുന്നെങ്കിൽ, വ്യത്യാസം എൻകാപ്സുലേഷൻ ഓവർഹെഡാണ്, ടണലിന്റെ അതിർത്തിയാണ് നിരസന സന്ദേശം ഉണ്ടാക്കേണ്ടിയിരുന്ന സ്ഥലം. ബന്ധിപ്പിക്കുന്നതിന് മുമ്പും ശേഷവും രണ്ട് സംഖ്യകളും രേഖപ്പെടുത്തുക, ആ ജോടിയാണ് തെളിവ്. അപ്ലിക്കേഷൻ IPv6 ഉപയോഗിക്കുമ്പോൾ അതിനും പരിശോധന ആവർത്തിക്കുക, കാരണം ഹെഡർ വലുതാണ്, പരാജയ പരിധി നീങ്ങുന്നു.

ടണലിനെ കുറ്റപ്പെടുത്തുന്നതിന് മുമ്പ് തെളിവുകൾ വായിക്കുക

വിദൂര അപ്ലിക്കേഷൻ പിഴവുകൾ, തിരക്ക്, സാധാരണ നഷ്ടം എന്നിവയും അപ്ലോഡുകൾ നിർത്തുന്നു, അതിനാൽ ഒരു പരാജയപ്പെട്ട കൈമാറ്റം കറുത്ത കുഴിയെ തിരിച്ചറിയുന്നില്ല. അവയെ വേർതിരിക്കുന്നത് വലിപ്പ ബന്ധമാണ്: 1200 ബൈറ്റിൽ ആവർത്തിക്കാവുന്ന വിജയവും 1400 ബൈറ്റിൽ ആവർത്തിക്കാവുന്ന നിലയ്ക്കലും, അതേ ദിശയിൽ, അതേ അന്തിമ ബിന്ദുവിലൂടെ.

ഇരു അറ്റങ്ങളിലെയും ക്യാപ്ചർ വലിയ പാക്കറ്റുകൾ പുറപ്പെട്ട് ഒരിക്കലും എത്തുന്നില്ല എന്ന് കാണിക്കുന്നു, ഇടയിൽ നിരസനമില്ലാതെ. സർവറിനു പകരം അതിർത്തി ഉപകരണത്തിലേക്ക് നോക്കേണ്ട നിമിഷമാണത്, കാരണം സർവർ തനിക്ക് യഥാർത്ഥത്തിൽ ലഭിക്കുന്ന ഓരോ അഭ്യർത്ഥനയ്ക്കും ഉത്തരം നൽകുന്നു. തിരക്കും നിർത്തുന്നു, പക്ഷേ അത് വ്യത്യസ്ത സമയങ്ങളിൽ വ്യത്യസ്ത വലിപ്പങ്ങൾ നിർത്തുന്നു, അത് വേറെ ഒപ്പമാണ്.

രണ്ട് ഗതാഗതങ്ങളിലും അറ്റകുറ്റപ്പണി പരിശോധിക്കുക

പിന്തുണയ്ക്കുന്ന അറ്റകുറ്റപ്പണി അതിർത്തിയെ യഥാർത്ഥ പരിധി റിപ്പോർട്ട് ചെയ്യാൻ അനുവദിക്കുകയോ, അവിടെ TCP-യുടെ പരമാവധി സെഗ്മെന്റ് വലിപ്പം മുറുക്കുകയോ ചെയ്യുകയാണ്, അതുവഴി വലിയ സെഗ്മെന്റ് പരീക്ഷിക്കപ്പെടില്ല. നെറ്റ്വർക്കിലെ എല്ലാ MTU-യും കുറയ്ക്കുകയോ ഫയർവാൾ ഓഫാക്കുകയോ ചെയ്യുന്നത് ലക്ഷണം മറയ്ക്കുകയും പിന്നീട് ആർക്കും വാദിക്കാനാകാത്ത ഒരു കോൺഫിഗറേഷൻ അവശേഷിപ്പിക്കുകയും ചെയ്യുന്നു.

ip link show dev tun0
sudo nft list ruleset | grep -i -E 'mtu|mss'
sysctl net.ipv4.tcp_mtu_probing
ping -M do -s 1400 -c 2 192.0.2.20

അതേ വലിപ്പ പരിശോധന ഉപയോഗിച്ച് പരിശോധിക്കുക, പിന്നെ പരാജയപ്പെട്ട അപ്ലിക്കേഷൻ ഉപയോഗിച്ച്, ഒരു രണ്ടാം പ്രോട്ടോക്കോളും പരിശോധിക്കുക, കാരണം UDP അപ്ലിക്കേഷനുകൾക്ക് TCP-യുടെ സെഗ്മെന്റ് വലിപ്പ തിരുത്തൽ ഒരിക്കലും ലഭിക്കുന്നില്ല. ടിക്കറ്റിൽ യഥാർത്ഥ മൂല്യങ്ങൾ സൂക്ഷിക്കുക, കാരണം തിരികെ മാറ്റാനാകാത്ത അറ്റകുറ്റപ്പണി സംഭവിക്കാൻ കാത്തിരിക്കുന്ന രണ്ടാം പ്രശ്നമാണ്. വലിപ്പ പരിശോധന വിജയിച്ചിട്ടും അപ്ലോഡ് നിലയ്ക്കുന്നെങ്കിൽ, കറുത്ത കുഴിയല്ല കാരണം, മാറ്റം വിശാലമാക്കുന്നതിനു പകരം അന്വേഷണം മുന്നോട്ടു പോകണം.