ചെറിയ അഭ്യർത്ഥനകൾ പ്രവർത്തിക്കുന്നു, വലിയ ഡൗൺലോഡുകൾ കുടുങ്ങുന്നു, പിന്നെ ആരോ MSS ക്ലാമ്പിംഗ് നിർദ്ദേശിക്കുന്നു. ആ നിർദ്ദേശം ശരിയായ ക്രമത്തിൽ പരീക്ഷിക്കാൻ തക്കവണ്ണം പലപ്പോഴും ശരിയാണ്, കണ്ണുമടച്ച് പ്രയോഗിച്ചാൽ ഒരു ഉച്ചയ്ക്ക് കളയാൻ തക്കവണ്ണം പലപ്പോഴും തെറ്റാണ്. താഴെയുള്ള മൂന്ന് പരിശോധനകൾ യഥാർത്ഥ TCP വലിപ്പ പ്രശ്നത്തെ UDP പ്രശ്നത്തിൽ നിന്നും കേടായ path-MTU കണ്ടെത്തലിൽ നിന്നും പുനർലേഖനം ചെയ്യേണ്ട ഹാൻഡ്‌ഷേക്ക് ഒരിക്കലും കാണാത്ത ക്ലാമ്പിൽ നിന്നും വേർതിരിക്കുന്നു.

പരാജയത്തിന്റെ രൂപത്തിൽ നിന്ന് തുടങ്ങുക

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

ഈ ഒപ്പ് ഉള്ളത് സെഗ്മെന്റ് വലിപ്പം ഹാൻഡ്‌ഷേക്കിലാണ് സമ്മതിക്കുന്നത് എന്നതുകൊണ്ടാണ്. ഓരോ വശവും പരമാവധി സെഗ്മെന്റ് വലിപ്പം TCP ഓപ്ഷനായി പ്രഖ്യാപിക്കുന്നു, അയയ്ക്കുന്നവർ എതിർവശത്തിന്റെ പ്രഖ്യാപനത്തെ മാനിക്കുന്നു. വഴിക്ക് അത്ര വലിയ സെഗ്മെന്റ് വഹിക്കാനാവില്ലെങ്കിൽ, പരാജയം പിന്നീട്, അയയ്ക്കുന്നയാൾ ഒടുവിൽ ഒന്ന് പരീക്ഷിക്കുമ്പോൾ പ്രത്യക്ഷപ്പെടുന്നു.

ഈ ലക്ഷണം വായിക്കുമ്പോൾ ഗതാഗതം കാഴ്ചയിൽ നിർത്തുക. ക്ലാമ്പിംഗ് TCP ഓപ്ഷന്റെ പുനർലേഖനമാണ്, അതിനാൽ അതേ ടണലിനടിയിൽ നിലയ്ക്കുന്ന വോയ്സ് അല്ലെങ്കിൽ വീഡിയോ കോൾ MSS പ്രശ്നമല്ല, അതുകൊണ്ട് മെച്ചപ്പെടുകയുമില്ല. TCP ഓപ്ഷനിൽ തൊടുന്നതിന് മുമ്പ് ഗതാഗതം എഴുതിവയ്ക്കുക.

വഴിയുടെ വില കണക്കാക്കി ടണലുമായി താരതമ്യം ചെയ്യുക

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

ping -M do -s 1400 198.51.100.20
tracepath 198.51.100.20

do-not-fragment ബിറ്റുള്ള ping ആ പേലോഡ് വലിപ്പത്തിലുള്ള പാക്കറ്റ് അതിജീവിക്കുന്നുണ്ടോ എന്ന് പറയുന്നു; പരാജയപ്പെടുന്നതുവരെ വലിപ്പം മാറ്റുക, വഴിയുടെ പരിധി പ്രായോഗികമായി കണ്ടെത്തി. tracepath-ന്റെ ഔട്ട്പുട്ട് വഴിയിലുടനീളം കണ്ടെത്തിയ MTU റിപ്പോർട്ട് ചെയ്യുന്നു, അത് പ്രവർത്തിക്കുമ്പോൾ വേഗതയേറിയതും ഇടയ്ക്കുള്ള ഹോപ്പ് പ്രോബുകൾ ഫിൽട്ടർ ചെയ്യുമ്പോൾ കുറച്ചുകൂടി വിശ്വാസയോഗ്യമല്ലാത്തതുമാണ്.

ഇപ്പോൾ ടണലിന്റെ ഓവർഹെഡ് കുറയ്ക്കുക. പുറം IP ശീർഷകം, UDP ശീർഷകം, ടണൽ-നിർദ്ദിഷ്ട ശീർഷകം എന്നിവയെല്ലാം അതേ 1500 ബൈറ്റിൽ നിന്നാണ് വരുന്നത്, അതിനാൽ സാധാരണ ഈതർനെറ്റ് അടിത്തറയിൽ ഉപയോഗയോഗ്യമായ ആന്തരിക MTU ഭൗതിക ലിങ്ക് സൂചിപ്പിക്കുന്നതിനേക്കാൾ കുറവാണ്. കണക്കാക്കിയ ആന്തരിക MTU നിങ്ങളുടെ പങ്കാളികൾ പ്രഖ്യാപിക്കുന്നതിനേക്കാൾ കുറവാണെങ്കിൽ, ഊഹമല്ല, യഥാർത്ഥ ക്ലാമ്പ് സ്ഥാനാർത്ഥിയെ കണ്ടെത്തി. കണക്കാക്കിയ മൂല്യം ഇതിനകം പങ്കാളികളുടെ പ്രഖ്യാപനത്തിന് മുകളിലാണെങ്കിൽ, ഇവിടെ നിർത്തി മറ്റെവിടെയെങ്കിലും നോക്കുക.

ഹാൻഡ്‌ഷേക്ക് കടന്നുപോകുന്നിടത്ത് ക്ലാമ്പ് വയ്ക്കുക

ക്ലാമ്പ് ഗേറ്റ്‌വേ കടക്കുമ്പോൾ SYN, SYN-ACK പാക്കറ്റുകളിലെ MSS ഓപ്ഷൻ പുനർലേഖനം ചെയ്താണ് പ്രവർത്തിക്കുന്നത്. രണ്ട് ദിശകളും ഒരിക്കലും കടക്കാത്ത ഇന്റർഫേസിലാണ് നിയമം ഇരിക്കുന്നതെങ്കിൽ, ചർച്ച മാറ്റമില്ലാതെ പൂർത്തിയാകുന്നു, ലക്ഷണം നിലനിൽക്കുന്നു, അതുകൊണ്ട് മൂല്യത്തെക്കാൾ സ്ഥാനമാണ് ഫലം തീരുമാനിക്കുന്നത്.

SymptomWhat it points toNext check
Handshake completes, large transfer stallsSegment size larger than the path can carryPath MTU against the tunnel's effective MTU
Nothing connects, small or largeRouting, firewall or keying failureNot MSS; look at the tunnel state
Only UDP applications stallDatagram size or a dropped ICMP errorPlatform-specific UDP handling, not clamping
Fixed after reconnect, returns laterClamp applied to one direction or one interfaceRule placement and the handshake path

ദിശയാണ് മറ്റേ പകുതി. ഒരു ദിശ മാത്രം ക്ലാമ്പ് ചെയ്താൽ പകുതി പ്രവാഹങ്ങൾ ശരിയാകും, ബാക്കിയുള്ളവ ഇടയ്ക്കിടെ എന്നപോലെ പരാജയപ്പെടും, അതിനാൽ കൈമാറ്റം ചെയ്യുന്ന ട്രാഫിക്കിന്റെ രണ്ട് ദിശകളിലും പ്രയോഗിക്കുക. ടണൽ ഇന്റർഫേസിനുള്ള ക്ലാസിക് Linux രൂപം SYN പാക്കറ്റുകളുമായി പൊരുത്തപ്പെടുന്ന mangle നിയമമാണ്:

iptables -t mangle -A FORWARD -o tun0 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

--clamp-mss-to-pmtu യഥാർത്ഥത്തിൽ എന്താണ് ചെയ്യുന്നതെന്ന് ശ്രദ്ധിക്കുക: അത് മൂല്യം റൂട്ടിന്റെ MTU-വിൽ നിന്ന് കണക്കാക്കുന്നു, അത് എപ്പോഴും ടണലിന്റെ യഥാർത്ഥ പേലോഡ് ബജറ്റല്ല. ആന്തരിക റൂട്ടും പുറം വഴിയും വ്യത്യസ്തമാകുന്ന റൂട്ട് അധിഷ്ഠിത ടണലിൽ, മുമ്പത്തെ പരിശോധനയിൽ കണക്കാക്കിയ വ്യക്തമായ മൂല്യം സ്വയമേവയുള്ളതിനേക്കാൾ പ്രവചനീയമാണ്.

പുതിയ കണക്ഷൻ ഉപയോഗിച്ച് പരിശോധിക്കുക, ഫീഡ്ബാക്ക് ജീവനോടെ നിർത്തുക

സ്ഥാപിതമായ കണക്ഷൻ ചർച്ച ചെയ്ത MSS നിലനിർത്തുന്നു, അതിനാൽ അതേ സെഷനിൽ പരീക്ഷിക്കുന്നത് ഒന്നും തെളിയിക്കുന്നില്ല. മാറ്റത്തിന് ശേഷം പുതിയ കണക്ഷൻ തുറന്ന് ചർച്ച ചെയ്ത മൂല്യം നേരിട്ട് വായിക്കുക, യാദൃച്ഛികമായി പൂർത്തിയാകുന്ന കൈമാറ്റത്തിൽ നിന്ന് അനുമാനിക്കുന്നതിന് പകരം.

ss -tin dst 198.51.100.20
iptables -t mangle -S | grep TCPMSS

ആദ്യ കമാൻഡ് സോക്കറ്റിന്റെ MSS അതിന്റെ തിരക്ക് നിലയോടൊപ്പം റിപ്പോർട്ട് ചെയ്യുന്നു, അതാണ് ക്ലാമ്പ് പ്രവർത്തിച്ചുവെന്നതിന്റെ വേഗതയേറിയ സ്ഥിരീകരണം. രണ്ടാമത്തേത് നിങ്ങൾ ചേർത്തതായി കരുതുന്ന നിയമം നിലവിലുള്ള നിയമമാണെന്ന്, അത് വയ്ക്കപ്പെട്ട പട്ടികയിൽ സ്ഥിരീകരിക്കുന്നു.

പിന്നെ നിങ്ങൾ ശരിയാക്കാത്ത സംവിധാനം സംരക്ഷിക്കുക. path-MTU കണ്ടെത്തൽ ICMP fragmentation-needed സന്ദേശങ്ങൾ അയയ്ക്കുന്നയാളിലേക്ക് എത്തുന്നതിനെ ആശ്രയിക്കുന്നു, അതിനാൽ അവ വലിച്ചെറിയുന്ന ഫയർവാൾ ശരിയായ ക്ലാമ്പ് ഉണ്ടായിരുന്നാലും വലിയ കൈമാറ്റങ്ങൾ തകർക്കുന്നത് തുടരും. ടണൽ വഴിക്ക് ആ സന്ദേശങ്ങൾ അനുവദിക്കുക, അല്ലെങ്കിൽ ക്ലാമ്പിംഗ് നിങ്ങൾ തിരഞ്ഞെടുത്ത നയത്തിന് നഷ്ടപരിഹാരം നൽകുന്നുവെന്ന് സ്വീകരിക്കുക.

അവസാനം, ക്ലാമ്പിനെ ട്യൂണിംഗ് നോബായി കാണാനുള്ള പ്രലോഭനത്തെ ചെറുക്കുക. അത് സെഗ്മെന്റ് വലിപ്പം പരിമിതപ്പെടുത്തുന്നു, അത് ഒരിക്കലും അതിന്റെ ആവശ്യമില്ലാത്ത വഴികളിൽ ത്രൂപുട്ട് ചെലവാക്കുന്നു. മൂന്ന് പരിശോധനകൾക്ക് ശേഷം പ്രയോഗിച്ചാൽ അത് ലക്ഷ്യബോധമുള്ള അറ്റകുറ്റപ്പണിയാണ്; ആദ്യം പ്രയോഗിച്ചാൽ അത് യഥാർത്ഥ തകരാറിനെ മറച്ച് ഓരോ പിന്നീടുള്ള പരീക്ഷണത്തിലും രണ്ടാമതൊരു ചരം ചേർക്കുന്ന മാറ്റമാണ്. ആ കൈമാറ്റം ബോധപൂർവം ചെയ്യാൻ യോഗ്യമാണ്, സ്വതവേയല്ല.

അളന്ന path-MTU, കുറച്ച ടണൽ ഓവർഹെഡ്, ചേർത്ത നിയമം, പിന്നീട് കണ്ട MSS എന്നിവ എഴുതിവയ്ക്കുക. നാല് സംഖ്യകൾ അടുത്ത സംഭവത്തെ അന്വേഷണത്തിന് പകരം തിരച്ചിലാക്കി മാറ്റുന്നു.

അനുബന്ധ ലേഖനങ്ങൾ