Linux-ൽ ഓരോ റൂട്ടിനും MTU: മൂന്ന് വലിപ്പ നിയന്ത്രണങ്ങൾ, ഒരു റൂട്ട്
ഇന്റർഫേസ് MTU, റൂട്ട് MTU, MSS പരിധി എന്നിവ വ്യത്യസ്ത പാളികളിൽ പ്രവർത്തിക്കുന്നു. തിരയലിൽ വിജയിക്കുന്ന റൂട്ടിന് ബജറ്റ് ബന്ധിപ്പിച്ച് മാറ്റം തിരികെ മാറ്റാവുന്നതായി സൂക്ഷിക്കുക.
Linux ക്ലയന്റിലെ മൂന്ന് ക്രമീകരണങ്ങളും «പാക്കറ്റുകൾ ചെറുതാക്കുക» എന്ന് കേൾക്കുന്നു, പക്ഷേ അവ വ്യത്യസ്ത പാളികളിൽ പ്രവർത്തിക്കുന്നു. ഇന്റർഫേസ് MTU ഉപകരണം അയക്കുന്ന ഓരോ പാക്കറ്റും പരിമിതപ്പെടുത്തുന്നു. റൂട്ട് MTU ആ റൂട്ട് ഉപയോഗിക്കുന്ന പാക്കറ്റുകൾ പരിമിതപ്പെടുത്തുന്നു, ഒരു VPN ലക്ഷ്യത്തിന് സാധാരണയായി അതാണ് നിങ്ങൾക്ക് യഥാർത്ഥത്തിൽ വേണ്ടത്. TCP MSS പരിധി രണ്ട് അറ്റങ്ങൾ ചർച്ച ചെയ്യുന്നത് മാറ്റുന്നു, UDP-യ്ക്ക് ഒന്നും ചെയ്യുന്നില്ല.
ഒരേ നോബ് പോലെ തോന്നുന്ന മൂന്ന് നിയന്ത്രണങ്ങൾ
തിരഞ്ഞെടുക്കുന്നതിന് മുമ്പ് അവ പരസ്പരം ഒപ്പം വയ്ക്കുക, കാരണം തെറ്റായ വരി തിരഞ്ഞെടുക്കുന്നതാണ് പ്രവർത്തിക്കാത്ത മിക്ക ഉപദേശങ്ങളെയും വിശദീകരിക്കുന്നത്:
| Control | Scope | What it cannot fix |
|---|---|---|
| Interface MTU | Every packet the device sends | Nothing, but it over-constrains unrelated traffic |
| Route MTU | Packets using that route | A send that the lookup never routes there |
| MSS clamp | TCP handshake on that path | UDP payload sizes and ICMP |
മുഴുവൻ മെഷീനും Ethernet MTU കുറയ്ക്കുന്നത് ഈ പരിഹാരത്തിന്റെ പരുക്കൻ പതിപ്പാണ്. അത് പ്രവർത്തിക്കുന്നു, കൂടാതെ ഹോസ്റ്റിലെ മറ്റെല്ലാ അപ്ലിക്കേഷനുകളെയും ശിക്ഷിക്കുന്നു, പാതകൾ കുഴപ്പമില്ലാതിരുന്നവയെയും. ഓരോ റൂട്ടിനുമുള്ള മൂല്യം അതേ ഉദ്ദേശ്യം പാർശ്വച്ചെലവില്ലാതെ പ്രകടിപ്പിക്കുന്നു.
ഹോസ്റ്റ് സ്വയം സൃഷ്ടിക്കുന്ന ട്രാഫിക്കിന് മാത്രമേ ഈ താരതമ്യം ബാധകമാകൂ. മറ്റൊരു ക്ലയന്റിനുള്ള പാക്കറ്റ് കൈമാറുന്നതിൽ അതിന്റെ സ്വന്തം പാതയും ടണലിന്റെ പുറം ബജറ്റും ഉൾപ്പെടുന്നു, ഈ ഹോസ്റ്റിലെ റൂട്ട് മെട്രിക് ആ അതിർത്തി കടക്കുന്നില്ല.
തിരയലിൽ വിജയിക്കുന്ന റൂട്ടിന് ബജറ്റ് ബന്ധിപ്പിക്കുക
ഒരു ഉദാഹരണ IPv4 റൂട്ട് റെക്കോർഡ് ഇങ്ങനെ കാണപ്പെടുന്നു:
ip -4 route get 10.60.0.20
ip -4 route add 10.60.0.0/16 dev tun-office src 10.90.0.2 mtu 1380റെക്കോർഡ് ഒട്ടിക്കാനുള്ള മൂല്യമായി അല്ല, ഉദ്ദേശ്യത്തിന്റെ വിവരണമായി വായിക്കുക. പ്രിഫിക്സും ഉപകരണവും മുൻഗണനാ ഉറവിടവും യഥാർത്ഥ കോൺഫിഗറേഷനുമായി പൊരുത്തപ്പെടണം, കൂടാതെ സംഖ്യ ബ്ലോഗ് പോസ്റ്റിൽ നിന്നല്ല, എൻകാപ്സുലേറ്റ് ചെയ്ത പാതയെക്കുറിച്ചുള്ള തെളിവിൽ നിന്ന് വരണം. റൂട്ട് MTU അകത്തെ IP പാക്കറ്റ് പരിമിതപ്പെടുത്തുന്നു, അത് 1380 ബൈറ്റ് TCP പേലോഡോ 1380 ബൈറ്റ് എൻക്രിപ്റ്റ് ചെയ്ത പുറം പാക്കറ്റോ അല്ല.
എന്തെങ്കിലും ചേർക്കുന്നതിന് മുമ്പ് തിരയൽ യഥാർത്ഥത്തിൽ എവിടെ പരിഹരിക്കുന്നു എന്ന് നോക്കുക. നയ നിയമങ്ങളുള്ള ഹോസ്റ്റിന് ഒരു ലക്ഷ്യം main ഒഴികെ മറ്റൊരു പട്ടിക വഴി റൂട്ട് ചെയ്യാം, കൂടാതെ main പട്ടികയിൽ മാത്രമുള്ള മെട്രിക് ആ അഭ്യർത്ഥനയ്ക്ക് അദൃശ്യമാണ്. താരതമ്യം ചെയ്യുക ip -4 route show table all ഉം ip route get ഉത്തരവും, നിയമങ്ങൾ ഉപയോഗിക്കുമ്പോൾ മാർക്ക് അല്ലെങ്കിൽ നെയിംസ്പേസ് സന്ദർഭം ഉൾപ്പെടെ. രണ്ടും പൊരുത്തപ്പെടുന്നില്ലെങ്കിൽ, മെട്രിക് ആവശ്യമുള്ളത് ഉത്തരം നൽകിയ പട്ടികയ്ക്കാണ്, കൂടുതൽ ചിട്ടയായി തോന്നുന്നതിനല്ല.
mtu എന്നത് mtu lock അല്ല
സ്വതേ കർണലിന് ICMP ഫീഡ്ബാക്കിൽ നിന്ന് പാത MTU അപ്ഡേറ്റ് ചെയ്യാം, പാത MTU കണ്ടെത്തൽ അതിനാണ്. lock ചേർക്കുന്നത് അത് നിർത്തുന്നു. ഇത് വേറെ തീരുമാനമാണ്, അതേ സംഖ്യ സൂക്ഷിക്കാനുള്ള ശക്തമായ വഴിയല്ല, IPv4-യിൽ «വിഭജിക്കരുത്» ബിറ്റിന്റെ രേഖപ്പെടുത്തിയ കൈകാര്യം മാറ്റുന്നു.
പാത അളന്ന്, എന്ത് വന്നാലും മൂല്യം സ്ഥിരമായിരിക്കണമെന്ന് ആഗ്രഹിക്കുമ്പോൾ ലോക്ക് ചെയ്യുന്നത് ന്യായമാണ്. നെറ്റ്വർക്ക് സാധുവായ വലിപ്പ ഫീഡ്ബാക്ക് അയക്കുമ്പോൾ ഇത് മോശം സ്വതേ മൂല്യമാണ്, കാരണം കർണലിന് ഇനി ക്രമീകരിക്കാനാകില്ല, പരാജയം മറ്റൊരു ലക്ഷണത്തിലേക്ക് നീങ്ങുന്നു.
പാതയിൽ എവിടെയെങ്കിലും ICMP ഫിൽട്ടർ ചെയ്യപ്പെട്ടാൽ, ഒരു റൂട്ട് ക്രമീകരണവും അത് ശരിയാക്കുന്നില്ല. പരിഹാരം ഫിൽട്ടറിനുള്ളതാണ്, ചെറിയ MTU അടുത്ത പാത മാറ്റം വരെ യഥാർത്ഥ തകരാറ് മറയ്ക്കുന്ന താൽക്കാലിക വഴിയാണ്.
ടണൽ സോഫ്റ്റ്വെയർ സ്വന്തം വലിപ്പ നോബുകൾ ചേർക്കുന്നു
OpenVPN- mssfix അതിന്റെ രേഖപ്പെടുത്തിയ UDP ടണൽ കേസിന് TCP സെഗ്മെന്റ് വലിപ്പം ക്രമീകരിക്കുന്നു. അത് TCP സംഭാഷണത്തിൽ പ്രവർത്തിക്കുന്നു, അതിനാൽ ഇത് ഓപ്പറേറ്റിംഗ് സിസ്റ്റത്തിന്റെ റൂട്ട് MTU-യുടെ മറ്റൊരു അക്ഷരവിന്യാസമല്ല, ചർച്ച അവഗണിക്കുന്ന UDP സേവനത്തെ സഹായിക്കാനാകില്ല.
ഒരേ മാറ്റ വിൻഡോയിൽ റൂട്ട് MTU, ഇന്റർഫേസ് MTU മാറ്റം, MSS പരിധി എന്നിവ ഒരുമിച്ച് വയ്ക്കരുത്. പ്രശ്നം മാറിയാൽ ഏതാണ് പ്രധാനമായിരുന്നതെന്ന് അറിയില്ല, നിലനിർത്തുന്നവ വർഷങ്ങളോളം ട്രാഫിക് പരിമിതപ്പെടുത്തും, കാരണം ആരും ഓർക്കുന്നില്ല.
അത് തിരികെ മാറ്റാവുന്നതാക്കുക, പിന്നെ തെളിയിക്കുക
റൂട്ടിന്റെ യഥാർത്ഥ ഉടമ മാറ്റം വീണ്ടും ബന്ധിപ്പിക്കലിന് ശേഷം നിലനിൽക്കുന്നുണ്ടോ എന്ന് തീരുമാനിക്കുന്നു. റൂട്ട് ചലനാത്മകമായി ഇൻസ്റ്റാൾ ചെയ്യുന്ന VPN ക്ലയന്റ് സാധാരണയായി നിങ്ങളുടെ മെട്രിക് ഇല്ലാതെ അത് വീണ്ടും നിർമ്മിക്കും, കൈകൊണ്ടുള്ള ip route add പിന്നീട് ഒരു ദിവസത്തിന് ശേഷം പരാജയപ്പെട്ട പരിഹാരം പോലെ തോന്നുന്നു. മൂല്യം മാനേജറുടെ കോൺഫിഗറേഷനിൽ വയ്ക്കുക, താൽക്കാലിക പരീക്ഷണം വേണമെങ്കിൽ ആദ്യം യഥാർത്ഥ റൂട്ട് രേഖപ്പെടുത്തുക.
കുടുങ്ങിയ പ്രവർത്തനം ചെയ്യുന്ന പുതിയ കണക്ഷൻ ഉപയോഗിച്ച് പരിശോധിക്കുക, തുടർന്ന് ഉദ്ദേശിച്ച സ്വകാര്യ റൂട്ട് ഇപ്പോഴും വിജയിക്കുന്നുവെന്നും ബന്ധമില്ലാത്ത ലക്ഷ്യങ്ങൾ മാറിയിട്ടില്ലെന്നും സ്ഥിരീകരിക്കുക. ടണൽ വീണ്ടും ബന്ധിപ്പിച്ച് റൂട്ട് വീണ്ടും വായിക്കുക, കാരണം വീണ്ടും ബന്ധിപ്പിക്കുമ്പോൾ അപ്രത്യക്ഷമാകുന്ന മൂല്യം പരിഹാരമല്ല.
തെളിവുകൾ മാറ്റത്തെ പിന്തുണയ്ക്കുന്നില്ലെങ്കിൽ, മാനേജർ വഴി ഓവർറൈഡ് നീക്കം ചെയ്ത് റൂട്ട് ഇല്ലാതാക്കുന്നതിന് പകരം യഥാർത്ഥ റൂട്ട് ഗുണങ്ങൾ പുനഃസ്ഥാപിക്കുക. തുടർന്ന് എന്താണ്, ഏത് പാതയിൽ അളന്നതെന്ന് എഴുതുക, അടുത്ത വ്യക്തിക്ക് യഥാർത്ഥ മെച്ചപ്പെടുത്തലിനെ പ്രവർത്തനത്തിൽ വിട്ട പരീക്ഷണത്തിൽ നിന്ന് വേർതിരിക്കാനാകാൻ.