VPN ഗേറ്റ്വേ വീണ്ടും ആരംഭിച്ചാലും IPv4 ഫോർവേഡിംഗ് നിലനിൽക്കുന്നതാക്കുക

ഗേറ്റ്വേയിലേക്കുള്ള പിംഗ് പ്രവർത്തിക്കുന്നു, അതിനു പിന്നിലെ ഒന്നിലും എത്തുന്നില്ല, ഇത് ടണൽ പ്രശ്നത്തിന്റെയല്ല, ഫോർവേഡിംഗ് പ്രശ്നത്തിന്റെ രൂപമാണ്. ഗേറ്റ്വേയിലേക്കുള്ള പ്രാദേശിക ഡെലിവറി ടണൽ ഉയർന്നുവെന്നും വിലാസ അനുവദനം പ്രവർത്തിച്ചുവെന്നും തെളിയിക്കുന്നു; കെർണൽ ഒരു ഇന്റർഫേസിൽ നിന്ന് മറ്റൊന്നിലേക്ക് പാക്കറ്റ് കൈമാറുമോ എന്നതിനെക്കുറിച്ച് അത് ഒന്നും പറയുന്നില്ല. ഏതെങ്കിലും sysctl തൊടുന്നതിന് മുമ്പ്, യന്ത്രം ഈ ട്രാഫിക് റൂട്ട് ചെയ്യാൻ ഉദ്ദേശിച്ചതാണെന്ന് ഉറപ്പാക്കുക കൂടാതെ ക്ലയന്റിന് അഭിമുഖമായ ഇന്റർഫേസ് ഉള്ള നെറ്റ്വർക്ക് സന്ദർഭം കണ്ടെത്തുക. തുടർന്ന് മൂല്യം അവിടെ വായിക്കുക, നിങ്ങൾ വായിച്ച അവസാന ഗൈഡ് യാദൃച്ഛികമായി നോക്കിയിടത്തല്ല.

ഗേറ്റ്വേയിൽ എത്തുന്നത് ഫോർവേഡിംഗ് അല്ല

കെർണലിനുള്ളിൽ രണ്ട് വേറിട്ട തീരുമാനങ്ങൾ നടക്കുന്നു. പ്രാദേശിക വിലാസത്തിലേക്കുള്ള ഡെലിവറി പാക്കറ്റിന്റെ യാത്ര അവസാനിപ്പിക്കുന്നു; ഫോർവേഡിംഗ് അതിനെ മറ്റൊരു ഇന്റർഫേസിലൂടെ വീണ്ടും പുറത്തേക്ക് അയയ്ക്കുന്നു, ആ രണ്ടാം തീരുമാനം ഓരോ നെറ്റ്വർക്ക് നെയിംസ്പേസിനും നിയന്ത്രിക്കപ്പെടുന്നു. ഫോർവേഡിംഗ് ഓഫ് ആയിരിക്കുമ്പോഴും ഗേറ്റ്വേ പൂർണ്ണമായി ലഭ്യമായിരിക്കാം, പിംഗ് പ്രോംപ്റ്റിൽ നിന്ന് ആ രണ്ട് പരാജയങ്ങളും ഒരേപോലെ തോന്നും.

ക്ലയന്റ് പാക്കറ്റ് ഏത് ഇന്റർഫേസിലേക്ക് വരുന്നു, അടുത്ത വഴി ഏത് ഇന്റർഫേസിലൂടെ പുറപ്പെടുന്നു എന്ന് എഴുതുക. രണ്ടും ഒരു നെയിംസ്പേസിൽ പെടുന്നു, പ്രധാനമായ ക്രമീകരണം ആ നെയിംസ്പേസിലാണ്.

പാക്കറ്റുകൾ യഥാർത്ഥത്തിൽ ഉള്ളിടത്ത് മൂല്യം വായിക്കുക

ഹോസ്റ്റ് നെയിംസ്പേസിൽ റൂട്ട് ചെയ്യുന്ന ഗേറ്റ്വേയിൽ, ഒരു കമാൻഡ് ചോദ്യത്തിന് ഉത്തരം നൽകുന്നു: sysctl net.ipv4.ip_forward. ഇൻഗ്രെസ്സും അടുത്ത വഴിയും പേരിട്ട നെയിംസ്പേസിലാണെങ്കിൽ, ആ നെയിംസ്പേസിനോട് ചോദിക്കുക: ip netns exec vpn-gw sysctl net.ipv4.ip_forward. ഹോസ്റ്റ് മൂല്യം നെയിംസ്പേസ് മൂല്യത്തിന് പകരമല്ല, ഹോസ്റ്റിൽ ഒന്ന് ഉണ്ടായിരിക്കുന്നത് ഒന്നിന്റെയും തെളിവല്ല.

എല്ലാ റൂട്ടിംഗ് സന്ദർഭത്തിനും ip netns എന്നതിന് നൽകാൻ കഴിയുന്ന ലേബൽ ഉണ്ടാകണമെന്നില്ല. കണ്ടെയ്നർ റൺടൈമുകളും സേവനങ്ങളും സൗഹൃദപരമായ പേരിൽ ഒരിക്കലും രജിസ്റ്റർ ചെയ്യാത്ത നെയിംസ്പേസുകൾ സൃഷ്ടിക്കുന്നു, അവയ്ക്ക് നിങ്ങൾ റൺടൈമിന്റെ പരിശോധനാ ഉപകരണങ്ങൾ ഉപയോഗിക്കുന്നു. vpn-gw എന്നതിന് പകരം യഥാർത്ഥ പേരോ അതേ സന്ദർഭത്തിൽ എത്തുന്ന റൺടൈം സംവിധാനമോ ഇടുക, ഹോസ്റ്റ് തലത്തിൽ ഊഹിക്കുന്നത് നിർത്തുക.

ക്രമീകരണത്തിന് ഒരു ഉടമയെ നൽകുക

സാധാരണ systemd ഹോസ്റ്റ് ഗേറ്റ്വേയിൽ, സ്ഥിരമായ രൂപം അഡ്മിനിസ്ട്രേറ്റർ തിരഞ്ഞെടുത്ത പേരുള്ള drop-in ഫയലാണ്, ഉദാഹരണത്തിന് /etc/sysctl.d/60-vpn-forwarding.conf, അതിൽ net.ipv4.ip_forward = 1 ഉണ്ട്. ഫയൽ എഴുതുക, എന്നിട്ട് ലൈവ് അവസ്ഥയും മാറാൻ അതേ നിർദ്ദിഷ്ട ഫയൽ ലോഡ് ചെയ്യുക: sudo sysctl -p /etc/sysctl.d/60-vpn-forwarding.conf, തുടർന്ന് തിരികെ വായിച്ച് പരിശോധിക്കുക. ഫയലിന്റെ പേര് ഒരു ഉദാഹരണമാണ്, സംവരണം ചെയ്ത VPN പാതയല്ല, ആദ്യത്തെ സംഖ്യ പ്രധാനമാണ് കാരണം പിന്നീട് അടുക്കുന്ന ഫയലുകൾ വിജയിക്കുന്നു.

മുൻഗണന എന്നത് സ്ഥിരത നിശബ്ദമായി തകരുന്നിടമാണ്. വിതരണത്തിന്റെ ലോഡറും നിങ്ങളുടെ സ്വന്തം drop-in ഉം പരിശോധിക്കുക, കാരണം procps sysctl --system അവസാനം /etc/sysctl.conf ഉം വായിക്കുന്നു, അതേസമയം systemd ന്റെ sysctl.d ക്രമം തികച്ചും വേറെ ശ്രേണിയാണ്. പിന്നീടുള്ള അനുവദനം അതേ കീ തിരികെ വെക്കാം, നിങ്ങളുടെ ഫയൽ ശരിയായിരിക്കുമ്പോൾ ഫലപ്രദമായ മൂല്യം തെറ്റായിരിക്കും. ആ വാദം ജയിക്കാൻ നിലവിലുള്ള അഡ്മിനിസ്ട്രേറ്റർ ഫയൽ മേലെഴുതരുത്; ഉടമയെ കണ്ടെത്തി അവിടെ മാറ്റുക.

ബൂട്ടിന് ശേഷം സൃഷ്ടിച്ച നെയിംസ്പേസ് ഹോസ്റ്റ് drop-in ഒട്ടും നിയന്ത്രിക്കുന്നില്ല. അതിന്റെ ക്രമീകരണം അത് സൃഷ്ടിക്കുന്നതിന് സ്വന്തമാണ്, അത് കണ്ടെയ്നർ റൺടൈമോ നെയിംസ്പേസിന്റെ പ്രൊവിഷനിംഗ് യൂണിറ്റോ ആകട്ടെ. ചോദ്യം ഒഴിവാക്കാൻ കണ്ടെയ്നറിന് വിശാലമായ ഹോസ്റ്റ് അധികാരങ്ങൾ നൽകുന്നത് ശരിയായ ഉടമയെ തിരിച്ചറിയാൻ പത്ത് മിനിറ്റ് ചെലവഴിക്കുന്നതിനേക്കാൾ മോശം ഇടപാടാണ്.

സ്വിച്ച് തിരിക്കുന്നതിന് മുമ്പ് അതിന്റെ വില അറിയുക

ip_forward ഹാനികരമല്ലാത്ത ബൂളിയൻ അല്ല. കെർണൽ ഡോക്യുമെന്റേഷൻ സൂചിപ്പിക്കുന്നത് അത് മാറ്റുന്നത് മറ്റ് പല IPv4 പാരാമീറ്ററുകളും ഹോസ്റ്റിന്റെയോ റൂട്ടറിന്റെയോ സ്വതവേയുള്ള മൂല്യങ്ങളിലേക്ക് പുനഃസജ്ജമാക്കുന്നു എന്നാണ്, അതിനാൽ ഒരു ഡയഗ്നോസ്റ്റിക് തിരിക്കൽ മറ്റെവിടെയോ ചെയ്ത ട്യൂണിംഗ് വലിച്ചെറിയുകയും അത് ഒരിക്കലും പരാമർശിക്കാതിരിക്കുകയും ചെയ്യാം. അതിനെ അശ്രദ്ധമായി പ്രവർത്തിപ്പിക്കാവുന്ന ഒരു പരിശോധനയായി അല്ല, പാർശ്വഫലങ്ങളുള്ള ഒരു കോൺഫിഗറേഷൻ മാറ്റമായി കാണുക.

ക്ലയന്റ് ഒരു ഹോസ്റ്റിൽ എത്താൻ കഴിയാത്ത ഓരോ തവണയും അത് ഓഫും ഓണും ചെയ്യുന്നതും ഇത് ഒഴിവാക്കുന്നു. മൂല്യം ഇതിനകം ഒന്നാണെങ്കിൽ, തകരാർ വഴിയുടെ മറ്റെവിടെയോ ആണ്, അതേ കീ മൂന്നാം തവണ വീണ്ടും എഴുതിയാൽ അത് നീങ്ങില്ല.

സ്ഥിരത തെളിയിക്കുക, എന്നിട്ട് ബാക്കി വഴി പരിശോധിക്കുക

നാല് നിമിഷങ്ങളിൽ മൂല്യം തിരികെ വായിക്കുക: മാറ്റത്തിന് ശേഷം ഉടൻ, VPN ഇന്റർഫേസ് പ്രത്യക്ഷപ്പെട്ട ശേഷം, വീണ്ടും കണക്ട് ചെയ്ത ശേഷം, ആസൂത്രിത പുനരാരംഭത്തിന് ശേഷം. ആ പോയിന്റുകളിൽ ഏതെങ്കിലും തിരികെ പോകുന്ന മൂല്യത്തിന് രണ്ടാമത് ഒരു ഉടമയുണ്ട്, ഒരു തവണകൂടി എഴുതുന്നത് അടുത്ത റീബൂട്ട് വരെ അത് മറയ്ക്കുന്നു എന്നു മാത്രം.

ഫോർവേഡിംഗ് സജീവമായാലും മൂന്ന് കാര്യങ്ങൾ പരിശോധിക്കാൻ ബാക്കിയുണ്ട്. ക്ലയന്റിന് ലക്ഷ്യസ്ഥാനത്തേക്ക് ഒരു റൂട്ട് വേണം, ഗേറ്റ്വേയ്ക്ക് തുടർന്നുള്ള ഒരു റൂട്ടും അത് ഉപയോഗിക്കാനുള്ള അനുമതിയും വേണം, ലക്ഷ്യസ്ഥാനത്തിന് ക്ലയന്റിന്റെ ടണൽ വിലാസത്തിലേക്ക് ഒരു തിരിച്ചുവഴിയും വേണം. സ്വകാര്യ റൂട്ട് ചെയ്ത LAN ന് സ്വയമേവ NAT ആവശ്യമില്ല, അതിനാൽ മൂന്നിൽ ഏതാണ് കാണാത്തതെന്ന് അറിയുന്നതിന് മുമ്പ് masquerading ചേർക്കരുത്, ഗേറ്റ്വേയിൽ നിന്നല്ല, ഉദ്ദേശിച്ച ക്ലയന്റിൽ നിന്ന് പരിശോധിക്കുക, കാരണം ഗേറ്റ്വേയിൽ ഉത്ഭവിച്ച അഭ്യർത്ഥന നിങ്ങൾ ഇപ്പോൾ സജീവമാക്കിയ ഫോർവേഡിംഗ് വഴിയിൽ ഒരിക്കലും സ്പർശിക്കുന്നില്ല. IPv6 ന് സ്വന്തമായ ഫോർവേഡിംഗ്, റൂട്ടിംഗ് നയമുണ്ട്, അതിനാൽ പ്രവർത്തിക്കുന്ന IPv4 പരിശോധന അതിനെക്കുറിച്ച് ഒന്നും പറയുന്നില്ല.

drop-in പാത, നെയിംസ്പേസിന്റെ ഉടമ, തിരികെ വായിക്കാനുള്ള കമാൻഡ് എന്നിവ ഒരുമിച്ച് runbook ൽ സൂക്ഷിക്കുക. ഇത് അടുത്തതായി ഏറ്റെടുക്കുന്നയാൾക്ക് മൂല്യം വായിക്കാനും, ആരാണ് ഉടമയെന്ന് കാണാനും, പ്രശ്നം സ്ഥിരതയാണോ വഴിയുടെ ബാക്കി ഭാഗമാണോ എന്ന് ഒരു മിനിറ്റിനുള്ളിൽ തീരുമാനിക്കാനും കഴിയണം.