Linux IPsec ഗേറ്റ്‌വേയിലെ TCP MSS ക്ലാമ്പിംഗ്: എന്താണ് അത് പരിഹരിക്കുന്നത്

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

MSS-ലേക്ക് സൂചന നൽകുന്ന ലക്ഷണം

TCP ഹാൻഡ്‌ഷേക്കിൽ പരമാവധി സെഗ്മെന്റ് വലിപ്പത്തിൽ ചർച്ച ചെയ്യുന്നു. ആ മൂല്യം എൻകാപ്സുലേഷനുശേഷം പാതയ്ക്ക് വഹിക്കാവുന്നതിനേക്കാൾ വലുതാണെങ്കിൽ, അയയ്ക്കുന്നയാൾ ഒരിക്കലും എത്താത്ത സെഗ്മെന്റുകൾ നിർമ്മിക്കുന്നത് തുടരുന്നു, ആദ്യ റൗണ്ടിനുശേഷം കണക്ഷൻ നിലയ്ക്കുന്നു. ചെറിയ പ്രതികരണങ്ങൾ ഒതുങ്ങുന്നു; വലിയവ ഒതുങ്ങുന്നില്ല.

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

TCPMSS നിയമം എന്ത് ചെയ്യുന്നു, എന്ത് ചെയ്യുന്നില്ല

നിയമം കടന്നുപോകുന്ന TCP ഹാൻഡ്‌ഷേക്ക് പാക്കറ്റുകളിലെ MSS ഓപ്ഷൻ വീണ്ടും എഴുതുന്നു. അത് ടണൽ ഇന്റർഫേസിന്റെ MTU സജ്ജമാക്കുന്നില്ല, IPsec നയം മാറ്റുന്നില്ല, നിലവിലെ കെർണലുകളിൽ ഇതിനകം ചെറുതായ മൂല്യം ഉയർത്തുന്നതിനുപകരം പ്രഖ്യാപിത മൂല്യം കുറയ്ക്കുന്നു മാത്രം. അത് TCP-യെ മാത്രം സ്പർശിക്കുന്നു; UDP പേലോഡുകൾ, DNS സ്വഭാവം, ചർച്ച ചെയ്ത ട്രാഫിക് സെലക്ടറുകൾ എന്നിവ അതിന്റെ പരിധിക്ക് പുറത്താണ്.

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

നിയമം ആന്തരിക TCP പാതയിൽ വയ്ക്കുക

നയാധിഷ്ഠിത Linux ഗേറ്റ്‌വേയിൽ, ഫയർവാൾ കാണുമ്പോൾ കൈമാറ്റം ചെയ്ത പാക്കറ്റ് ഇപ്പോഴും സാധാരണ TCP പോലെ തോന്നുന്നു. IPsec നയം പാക്കറ്റ് സംരക്ഷിക്കപ്പെടുമെന്ന് തീരുമാനിക്കുന്നു; ഫയർവാൾ ആന്തരിക പ്രവാഹത്തിന് ESP ഹെഡർ കാണുന്നില്ല, അതിനാൽ ഇവിടെ ESP-യുമായി പൊരുത്തപ്പെടുത്തുന്നത് തികച്ചും വ്യത്യസ്തമായ ഒരു പാക്കറ്റിനെ വിവരിക്കുന്നു. ആ പൊരുത്തക്കേടാണ് ചില നിയമങ്ങൾ ശരിയായി തോന്നുകയും ഒരിക്കലും പൊരുത്തപ്പെടാതിരിക്കുകയും ചെയ്യുന്നതിന്റെ കാരണം.

iptables പദങ്ങളിൽ നിയമം ഫോർവേഡിംഗ് പാതയിലെ mangle പട്ടികയിൽ പെടുന്നു, ഹാൻഡ്‌ഷേക്ക് പാക്കറ്റുകളിൽ പരിമിതപ്പെടുത്തിയിരിക്കുന്നു: iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1270. സംഖ്യ ഒരു ഉദാഹരണമാണ്, സാർവത്രിക സ്ഥിരാങ്കമല്ല; എൻകാപ്സുലേഷൻ ഓവർഹെഡിൽ നിന്നും പാതയുടെ യഥാർത്ഥ MTU-വിൽ നിന്നും അത് കണ്ടെത്തുക. nftables തുല്യമായത് forward അല്ലെങ്കിൽ postrouting ശൃംഖലയിൽ പരമാവധി സെഗ്മെന്റ് വലിപ്പം സജ്ജമാക്കുന്നു.

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

ഫയർവാളിന്റെ ഉടമയെയും NAT ക്രമത്തെയും മാനിക്കുക

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

സ്രോതസ്സ് വിവർത്തനം ഇതുമായി പലപ്പോഴും പരസ്പരം പ്രവർത്തിക്കുന്ന വേറിട്ട തീരുമാനമാണ്. പൊതുവായ masquerade നിയമത്തിന് മുമ്പ് വയ്ക്കുന്ന ഒഴിവാക്കൽ സംരക്ഷിത ട്രാഫിക്കിന് അതിന്റെ നയം ആവശ്യപ്പെടുന്ന സ്രോതസ്സ് നഷ്ടപ്പെടുന്നത് തടയുന്നു; അത് വലിപ്പ പ്രശ്നം പരിഹരിക്കുന്നില്ല, വലിപ്പ നിയമം വിവർത്തന പ്രശ്നം പരിഹരിക്കുന്നുമില്ല.

സൂക്ഷ്മമായി പരിശോധിക്കുക, പിന്നെ നിർത്തുക

പരാജയപ്പെടുന്ന സേവനത്തിലേക്ക് പുതിയ കണക്ഷൻ തുറന്ന് ആപ്ലിക്കേഷനും നിയമത്തിന്റെ കൗണ്ടറുകളും നിരീക്ഷിക്കുക. നിലയ്ക്കൽ മാറിയാൽ, ആ എൻകാപ്സുലേഷനോടുകൂടിയ ആ TCP പാതയെക്കുറിച്ച് നിങ്ങൾക്ക് തെളിവുണ്ട്. എല്ലാ VPN പ്രോട്ടോക്കോളും യോജിക്കുന്നു, എല്ലാ UDP ആപ്ലിക്കേഷനും പരിഹരിച്ചു, അല്ലെങ്കിൽ ഒരു പ്രത്യേക അപ്സ്ട്രീം സേവനമായിരുന്നു യഥാർത്ഥ കാരണം എന്നതിന് തെളിവില്ല.

നയം അനുവദിക്കുന്നിടത്ത് ICMP വലിപ്പ ഫീഡ്ബാക്ക് പ്രവർത്തിക്കട്ടെ, പുറം IPsec പാത ആന്തരിക റൂട്ട് പ്രതിനിധീകരിക്കാത്തപ്പോൾ റൂട്ട്-MTU അടിസ്ഥാനമാക്കിയുള്ള യാന്ത്രിക ക്ലാമ്പിംഗ് ശ്രദ്ധയോടെ കൈകാര്യം ചെയ്യുക. നിഗമനം എത്ര സൂക്ഷ്മമോ, അടുത്ത സംഭവം രോഗനിർണയം ചെയ്യാൻ അത്ര എളുപ്പം.