WireGuard കുടുങ്ങുന്നു: MTU പരിധിയോ അല്ലെങ്കിൽ കാണാത്ത ഫോർവേഡ് നിയമമോ?

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

രണ്ട് പരാജയങ്ങൾ, രണ്ട് വ്യത്യസ്ത രൂപങ്ങൾ

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

വലുപ്പ പ്രശ്നം ഒരു പരിധിക്ക് മുകളിൽ മാത്രം പ്രത്യക്ഷപ്പെടുന്നു. DNS, TCP ഹാൻഡ്ഷേക്ക്, ചെറിയ API വിളി എന്നിവ പ്രവർത്തിക്കുന്നു, അതേസമയം ഫയൽ ഡൗൺലോഡോ വലിയ മറുപടിയോ തൂങ്ങുന്നു. ഒതുങ്ങിയ പാക്കറ്റുകൾ ഒരറ്റം മുതൽ മറ്റേ അറ്റം വരെ സഞ്ചരിച്ചു, ഒതുങ്ങാത്തവ ഉപയോഗപ്രദമായ റിപ്പോർട്ടില്ലാതെ എവിടെയോ വലിച്ചെറിയപ്പെട്ടു.

ആ വിവരണങ്ങൾ വ്യത്യസ്ത ആളുകളെയും വ്യത്യസ്ത കോൺഫിഗറേഷൻ ഫയലുകളെയും സൂചിപ്പിക്കുന്നു, അതിനാൽ ഊഹിക്കുന്നതിനേക്കാൾ രൂപം അളക്കുന്നതാണ് മൂല്യമുള്ളത്. ഗേറ്റ്വേയിലേക്കുള്ള ഒരു പിംഗിന് അവയെ വേർതിരിക്കാനാവില്ല.

എന്തെങ്കിലും ചെറുതാക്കുന്നതിന് മുമ്പ് ഫോർവേഡിംഗ് ഒഴിവാക്കുക

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

തിരിച്ചുവരവ് റൂട്ടിംഗും അത്രതന്നെ പ്രധാനമാണ്. ലക്ഷ്യ നെറ്റ്വർക്കിന് ക്ലയന്റിന്റെ ടണൽ വിലാസത്തിൽ എത്താനുള്ള വഴി അറിയില്ലെങ്കിൽ, അഭ്യർത്ഥന എത്തുകയും മറുപടി അപ്രത്യക്ഷമാകുകയും ചെയ്യുന്നു, ക്ലയന്റ് ഉപേക്ഷിക്കപ്പെട്ട ഫോർവേഡിന് സമാനമായി തോന്നുന്ന സമയപരിധി റിപ്പോർട്ട് ചെയ്യുന്നു.

ഡിസൈൻ വിലാസ പരിഭാഷ ഉപയോഗിക്കുന്നിടത്ത്, പരിഭാഷാ നിയമം ആ തിരിച്ചുവരവ് പാതയുടെ ഭാഗമാണ്. MTU പ്രശ്നത്തിന് പിന്നാലെ പോകുമ്പോൾ അത് നീക്കം ചെയ്യുന്നത് പ്രവർത്തിക്കുന്ന ഡിസൈനെ തകർന്നതാക്കി മാറ്റുന്നു, അതിനാൽ തിരുത്തുന്നതിന് മുമ്പ് നിലവിലുള്ള നിയമങ്ങൾ വായിക്കുക.

വിരിവ് എവിടെ തുടങ്ങുന്നു എന്ന് അളക്കുക

ആദ്യം ഫോർവേഡിംഗ് നിലയും ഫിൽട്ടർ നിയമങ്ങളും വായിക്കുക. ഇവ വായന മാത്രമുള്ള പരിശോധനകളാണ്, വിലകുറഞ്ഞ ചോദ്യത്തിന് മറുപടി നൽകുന്നു:

sysctl net.ipv4.ip_forward
sudo iptables -S FORWARD
ip route get 10.30.0.9

തുടർന്ന് ക്ലയന്റിൽ നിന്ന് ഗേറ്റ്വേയ്ക്കപ്പുറമുള്ള ഹോസ്റ്റിലേക്ക്, don’t-fragment ബിറ്റ് ഉപയോഗിച്ച് വലുപ്പങ്ങൾ പരിശോധിക്കുക:

ping -M do -s 1200 10.30.0.9
ping -M do -s 1400 10.30.0.9

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

നിങ്ങൾ തെളിയിച്ച ലെയർ നന്നാക്കുക

ഫോർവേഡിംഗാണ് തകരാറെങ്കിൽ, പരിഹാരം ഒരു ഫോർവേഡിംഗ് നിയമമോ റൂട്ടോ ആണ്, ഡിസൈൻ അനുവദിക്കുന്നത്ര സങ്കുചിതമായി പ്രകടിപ്പിക്കുന്നു. വലുപ്പമാണ് തകരാറെങ്കിൽ, പരിഹാരം ഈ നിർദ്ദിഷ്ട പാതയിലെ എൻകാപ്സുലേഷൻ കണക്കിലെടുക്കുന്ന MTU ആണ്, അത് ആവശ്യമുള്ള ഇന്റർഫേസിൽ പ്രയോഗിക്കുന്നു, കപ്പലിലെ എല്ലാ അഡാപ്റ്ററിലും അല്ല.

ഏതായാലും, അതിന് ശേഷം അതേ ലക്ഷ്യത്തിലേക്ക് അതേ ജോലി ആവർത്തിക്കുക. യഥാർത്ഥ വലിയ കൈമാറ്റം ഇപ്പോൾ പൂർത്തിയാകുന്നുവെങ്കിൽ, മാറ്റം പരാജയപ്പെട്ടിരുന്ന ലെയറിനെ അഭിസംബോധന ചെയ്തു. ചെറിയ പരിശോധന മാത്രം മെച്ചപ്പെട്ടുവെങ്കിൽ, നിങ്ങൾ ഒരു ലക്ഷണത്തിന് ചികിത്സിച്ചു, യഥാർത്ഥ പരിധി ഇപ്പോഴും അവിടെയുണ്ട്.

മാറ്റത്തിന് മുമ്പ് നിങ്ങൾ കണ്ട രൂപം എഴുതിവയ്ക്കുക. പരിഹാരത്തിന് അരികിൽ രേഖപ്പെടുത്തിയ ആ ഒരു വരിയാണ്, ഒരിക്കലും പ്രശ്നമല്ലാതിരുന്ന MTU കുറയ്ക്കുന്നതിൽ നിന്ന് അടുത്ത വ്യക്തിയെ തടയുന്നത്.