net.ipv4.conf.default.forwarding tun0-നെ എന്തുകൊണ്ട് തൊടാതെ വിടുന്നു

നിങ്ങൾ net.ipv4.conf.default.forwarding=1 സെറ്റ് ചെയ്തു, VPN വീണ്ടും ആരംഭിച്ചു, എന്നിട്ടും ഗേറ്റ്‌വേ റൂട്ട് ചെയ്യേണ്ട പാക്കറ്റുകൾ ടണൽ ഇപ്പോഴും ഉപേക്ഷിക്കുന്നു. ഫയലിലെ സെറ്റിംഗ് ശരിയായി കാണുന്നു, ഇന്റർഫേസ് ഇപ്പോഴും ഫോർവേർഡിംഗ് ഓഫാണെന്ന് റിപ്പോർട്ട് ചെയ്യുന്നു. ഒന്നും തകർന്നിട്ടില്ല: ഭാവിയിലെ ഇന്റർഫേസുകൾ പാരമ്പര്യമായി ലഭിക്കുന്ന മൂല്യമാണ് നിങ്ങൾ മാറ്റിയത്, സജീവമായ ടണൽ ഉപയോഗിക്കുന്നതല്ല.

ടണൽ ഉടമയായ ഹോസ്റ്റിൽ, ടണൽ യഥാർത്ഥത്തിൽ നിലനിൽക്കുന്ന നെറ്റ്‌വർക്ക് namespace-ൽ ഇത് പരിശോധിക്കുക. ഒരു കണ്ടെയ്നറോ നെറ്റ്‌വർക്ക് namespace-നോ ഇന്റർഫേസ് കൈവശം വയ്ക്കാം, ഹോസ്റ്റ് വേറെ സംഖ്യകൾ കാണിക്കുന്നു.

മൂന്ന് മൂല്യങ്ങളും ഒരുമിച്ച് വായിക്കുക

ഗേറ്റ്‌വേ മുഴുവൻ സ്വിച്ച്, പുതിയ ഇന്റർഫേസുകൾക്കുള്ള ടെംപ്ലേറ്റ്, നിങ്ങൾക്ക് പ്രധാനമായ ഇന്റർഫേസ് എന്നിവ താരതമ്യം ചെയ്ത് തുടങ്ങുക. tun0 എന്നതിനു പകരം യഥാർത്ഥ ഇൻപുട്ട് ഇന്റർഫേസ് ഇടുക, മടങ്ങിവരുന്ന ഇന്റർഫേസും വായിക്കുക, കാരണം പാക്കറ്റ് എത്തുന്ന ബിന്ദുവിലാണ് ഫോർവേർഡിംഗ് വിലയിരുത്തപ്പെടുന്നത്.

sysctl net.ipv4.ip_forward
sysctl net.ipv4.conf.default.forwarding
sysctl net.ipv4.conf.tun0.forwarding

സാധാരണ ഫലം ip_forward = 0, default.forwarding = 1 എന്നിവയും tun0.forwarding = 0 എന്നതുമാണ്. ആദ്യ രണ്ടെണ്ണം ഹോസ്റ്റിന്റെ പങ്കിനെക്കുറിച്ച് യോജിക്കുന്നില്ല, മൂന്നാമത്തേത് ഇന്റർഫേസ് യഥാർത്ഥത്തിൽ എന്തു ചെയ്യുന്നു എന്ന് കാണിക്കുന്നു. ഈ സംയോജനം ഒരിക്കലും റൂട്ടറായി കോൺഫിഗർ ചെയ്യപ്പെടാത്ത, ടെംപ്ലേറ്റ് മൂല്യം മാത്രം ലഭിച്ച ഹോസ്റ്റിനോട് യോജിക്കുന്നു. മൂന്ന് സംഖ്യകളും പരസ്പരവിരുദ്ധമല്ല; അവ മൂന്ന് വ്യത്യസ്ത ചോദ്യങ്ങൾക്ക് ഉത്തരം നൽകുന്നു. ടെംപ്ലേറ്റ് മൂല്യം എഴുതുന്നതും ഹോസ്റ്റിന്റെ പങ്ക് തീരുമാനിക്കുന്നില്ല.

എന്തുകൊണ്ട് ആഗോള സ്വിച്ചാണ് നീങ്ങുന്നത്

net.ipv4.ip_forward ഗേറ്റ്‌വേ മുഴുവൻ നിയന്ത്രണമാണ്. അത് മാറ്റുന്നത് അതേ പ്രവർത്തനത്തിന്റെ ഭാഗമായി ഓരോ ഇന്റർഫേസിന്റെയും ഫോർവേർഡിംഗ് ക്രമീകരണങ്ങൾ പുതുക്കുന്നു, അതിനാൽ ഒരു എഴുത്ത് തന്നെ നിലവിലുള്ള ടണലിനെ ഫോർവേർഡ് ചെയ്യാൻ തുടങ്ങിക്കാം. default.forwarding പിന്നീട് ആരംഭിക്കുന്ന ഇന്റർഫേസുകളെ മാത്രം വിതയ്ക്കുന്നു, അതിനാൽ നിലവിലുണ്ടായിരുന്ന ടണൽ ജനിച്ച മൂല്യം തന്നെ നിലനിർത്തുന്നു.

കേർണൽ ഡോക്യുമെന്റേഷൻ ip_forward ഒരു ബന്ധപ്പെട്ട കാരണത്താൽ പ്രത്യേകമായി അടയാളപ്പെടുത്തുന്നു: അത് മാറ്റുന്നത് മറ്റ് പല IPv4 പാരാമീറ്ററുകളും ഹോസ്റ്റ് അല്ലെങ്കിൽ റൂട്ടർ ഡിഫോൾട്ടുകളിലേക്ക് പുനഃസജ്ജമാക്കുന്നു. അത് ഇതിനെ ഒരു മൊഴി ഉപകരണമാക്കുന്നു. ഗേറ്റ്‌വേ പങ്ക് സ്ഥാപിക്കുന്നതിന്റെ ഭാഗമായി ഒരിക്കൽ സെറ്റ് ചെയ്യുന്നത് കുഴപ്പമില്ല; ഡീബഗ്ഗിംഗ് തന്ത്രമായി ആവർത്തിച്ച് ടോഗിൾ ചെയ്യുന്നത് നിങ്ങൾ സമയം ചെലവഴിച്ച് ശരിയാക്കിയ കോൺഫിഗറേഷൻ നിശബ്ദമായി മാറ്റിയെഴുതാം.

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

ക്രമീകരണം ശരിയായ സ്ഥലത്ത് സ്ഥിരമാക്കുക

ഒരു വിജയകരമായ ഒറ്റത്തവണ sysctl -w കേർണൽ മൂല്യം സ്വീകരിക്കുന്നു എന്ന് തെളിയിക്കുന്നു. അത് റീബൂട്ടിന് ശേഷം നിലനിൽക്കുന്നില്ല, വീണ്ടും ബന്ധിപ്പിക്കുമ്പോൾ ഇന്റർഫേസ് കോൺഫിഗറേഷനെക്കുറിച്ചുള്ള സ്വന്തം ധാരണ വീണ്ടും പ്രയോഗിക്കുന്ന നെറ്റ്‌വർക്ക് മാനേജറിന് ശേഷവും നിലനിൽക്കുന്നില്ല. ഗേറ്റ്‌വേ പങ്ക് sysctl കോൺഫിഗറേഷൻ ഫയലിലോ ഹോസ്റ്റിന്റെ ഉടമയായ നെറ്റ്‌വർക്ക് മാനേജറിലോ വയ്ക്കുക, തുടർന്ന് അത് പ്രയോഗിക്കുന്ന സേവനം വീണ്ടും ആരംഭിക്കുക.

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

VPN വീണ്ടും ബന്ധിപ്പിച്ചതിന് ശേഷവും വീണ്ടും റീബൂട്ടിന് ശേഷവും അതേ മൂന്ന് മൂല്യങ്ങൾ വീണ്ടും വായിക്കുക. പുതുതായി സൃഷ്ടിച്ച ടണൽ പുതിയ ഇന്റർഫേസാണ്, പുതിയ ഇന്റർഫേസ് സൃഷ്ടിയുടെ നിമിഷത്തിൽ പ്രാബല്യത്തിലുള്ള ഡിഫോൾട്ട് എടുക്കുന്നു. ഈ സംഭവങ്ങൾക്കിടയിൽ സംഖ്യകൾ മാറുന്നുവെങ്കിൽ, നിങ്ങൾ ഇതുവരെ തിരിച്ചറിയാത്ത എന്തോ ആണ് കോൺഫിഗറേഷൻ പ്രയോഗിക്കുന്നത്.

തെറ്റായ ഉപകരണം കൊണ്ട് ഇത് നന്നാക്കരുത്

ഫോർവേർഡിംഗ് തകർന്നതായി തോന്നിയപ്പോൾ, ഫയർവാൾ ഫ്ലഷ് ചെയ്യാനോ masquerading ചേർക്കാനോ പ്രലോഭനം തോന്നും. രണ്ടും ഫോർവേർഡിംഗ് സ്വിച്ചിനെ അഭിസംബോധന ചെയ്യുന്നില്ല. ഫോർവേർഡിംഗ് അവസ്ഥ, ഫോർവേർഡ് ചെയ്യാനുള്ള അനുമതി, ലക്ഷ്യത്തിലേക്കുള്ള റൂട്ട്, മടങ്ങിവരുന്ന പാത — ഇവ നാല് വേറിട്ട ആവശ്യകതകളാണ്, ആദ്യത്തേത് മാത്രമാണ് sysctl.

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

IPv6 കേസ് വേർതിരിച്ച് വയ്ക്കുക

ഇവിടെ എല്ലാം IPv4 ആണ്. IPv6 ഫോർവേർഡിംഗിനും റൂട്ടർ പ്രഖ്യാപനങ്ങൾക്കും accept_ra സ്വഭാവത്തിനും സ്വന്തം നിയന്ത്രണങ്ങളുണ്ട്, ipv4 പാത ipv6 സെറ്റിംഗിലേക്ക് പകർത്തുന്നത് വിശ്വസനീയമായി തോന്നുന്ന, എന്നാൽ ഉപയോഗപ്രദമായി ഒന്നും ചെയ്യാത്ത ഒരു ഫയൽ ഉണ്ടാക്കുന്നു. ഇരട്ട-സ്റ്റാക്ക് ഗേറ്റ്‌വേയ്ക്ക് രണ്ട് സെറ്റുകളും ബോധപൂർവം കോൺഫിഗർ ചെയ്യേണ്ടതുണ്ട്.

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