systemd-networkd-യുമായി വീണ്ടും കണക്റ്റ് ചെയ്താലും ip rule നിലനിർത്തുക
ഷെല്ലിൽ നിന്ന് ചേർത്ത ip നിയമം അടുത്ത ലിങ്ക് സംഭവത്തിൽ അപ്രത്യക്ഷമാകും. നിയമവും അതിന്റെ പട്ടികയും റൂട്ടുകളും systemd-networkd-ൽ പ്രഖ്യാപിക്കുക, അപ്പോൾ നയം വീണ്ടും സൃഷ്ടിക്കപ്പെടും.
ip rule ഉപയോഗിച്ച് ഒരു നയ-നിയമം ചേർക്കുക, ലിങ്ക് പോകുന്നതുവരെ അത് പ്രവർത്തിക്കും; ആ നിമിഷത്തിൽ അത് അവിടെ ഇല്ല. ഒന്നും ഉറക്കെ പരാജയപ്പെട്ടില്ല: കേർണൽ അവസ്ഥ മാറി, ആ നിയമം ഉണ്ടായിരിക്കണമെന്ന് ഏതെങ്കിലും കോൺഫിഗറേഷൻ ഉടമയ്ക്ക് അറിയില്ലായിരുന്നു. നിലനിൽക്കുന്നതും നിലനിൽക്കാത്തതുമായ നിയമങ്ങൾ തമ്മിലുള്ള മുഴുവൻ വ്യത്യാസം ഇതാണ്. systemd-networkd ഉള്ള ഹോസ്റ്റിൽ പരിഹാരം എന്നത് നിയമത്തിന് ഒരു ഉടമയെ നൽകുകയാണ്, ഓരോ വീണ്ടും കണക്ഷനു ശേഷവും കമാൻഡ് വീണ്ടും ഓടിക്കുന്നതല്ല.
ആരെങ്കിലും അതിനെ ഉടമസ്ഥതയിൽ കൈവശം വയ്ക്കുമ്പോൾ മാത്രമേ ഒരു നിയമം നിലനിൽക്കൂ
കേർണലിന്റെ റൂട്ടിംഗ് നയം അവസ്ഥയാണ്, കോൺഫിഗറേഷനല്ല. അത് പ്രവർത്തിക്കുന്ന സിസ്റ്റത്തിൽ ജീവിക്കുന്നു, അത് ആശ്രയിക്കുന്ന ഇന്റർഫേസ് തകർക്കുന്ന ഏതും അതിനെ കൂടെ കൊണ്ടുപോകാം. ഷെൽ കമാൻഡ് ആ അവസ്ഥ മാറ്റുന്നു, ഉദ്ദേശ്യത്തിന്റെ ഒരു രേഖയും അവശേഷിപ്പിക്കുന്നില്ല.
നെറ്റ്വർക്ക് മാനേജർമാർ വിപരീതമായി പ്രവർത്തിക്കുന്നു: അവർ കോൺഫിഗറേഷൻ വായിക്കുന്നു, പ്രയോഗിക്കുന്നു, ലിങ്ക് സംഭവം മുൻ അവസ്ഥ അസാധുവാക്കുമ്പോൾ വീണ്ടും പ്രയോഗിക്കുന്നു. അവരുടെ കോൺഫിഗറേഷനിൽ പ്രഖ്യാപിച്ച നിയമം വീണ്ടും സൃഷ്ടിക്കപ്പെടുന്നു, അവരുടെ അരികിൽ ചേർത്ത നിയമം ഉടമയില്ലാത്ത ഒരു ബാഹ്യ വസ്തുവാണ്.
ആ വ്യത്യാസത്തിന് networkd-ൽ ഒരു പേരുണ്ട്, എന്തെങ്കിലും പ്രവർത്തനക്ഷമമാക്കുന്നതിന് മുമ്പ് അത് വായിക്കേണ്ടതാണ്. സമീപകാല പതിപ്പുകളിൽ ബാഹ്യ നിയമങ്ങൾ സ്വതവേ നീക്കം ചെയ്യപ്പെടുന്നു, ഇത് തങ്ങളുടെ കൈയെഴുത്ത് എൻട്രികൾ നിലനിൽക്കുമെന്ന് പ്രതീക്ഷിച്ചവരെ അമ്പരപ്പിക്കുന്നു.
ഒരു ക്രമീകരണത്തിൽ വിശ്വസിക്കുന്നതിന് മുമ്പ് പതിപ്പ് വായിക്കുക
ഉടമസ്ഥതാ സ്വഭാവം networkd.conf-ലെ ഒരു ക്രമീകരണത്താൽ നിയന്ത്രിക്കപ്പെടുന്നു, ആ ക്രമീകരണം പഴയ systemd പതിപ്പുകളിൽ ഇല്ല. അതിനെ ആധാരമാക്കി രൂപകൽപ്പന ചെയ്യുന്നതിന് മുമ്പ് ഇൻസ്റ്റാൾ ചെയ്ത പതിപ്പ് പരിശോധിക്കുക, കാരണം പഴയ ഹോസ്റ്റ് നിങ്ങൾ വായിക്കുന്ന ഡോക്യുമെന്റേഷനിൽ നിന്ന് വ്യത്യസ്തമായി പെരുമാറും.
രണ്ട് മൂല്യങ്ങൾ പ്രധാനമാണ്. ഒന്ന് networkd കോൺഫിഗറേഷനിൽ പ്രഖ്യാപിക്കാത്ത നിയമങ്ങൾ നീക്കം ചെയ്യുന്നുണ്ടോ എന്ന് തീരുമാനിക്കുന്നു, മറ്റൊന്ന് റൂട്ടുകൾക്കും അതേ കാര്യം ചെയ്യുന്നു. രണ്ടും നയത്തിന്റെ ഉള്ളടക്കത്തെക്കുറിച്ചല്ല, ഉടമസ്ഥതയെക്കുറിച്ചാണ്, രണ്ടും നിലവിലെ പതിപ്പുകളിൽ സ്വതവേ കർശനമായ പെരുമാറ്റം തിരഞ്ഞെടുക്കുന്നു. അവ ആഗോളമായി ഓഫ് ചെയ്താൽ ഓരോ ബാഹ്യ നിയമവും ജീവനോടെ നിലനിൽക്കും, ഇത് ഒരു ഉദ്ദിഷ്ട VPN നയം പ്രഖ്യാപിക്കുന്നതിനേക്കാൾ വളരെ വിശാലമായ തീരുമാനമാണ്.
systemctl --version | head -1
networkctl --version | head -1
grep -R "ManageForeign" /etc/systemd/ /usr/lib/systemd/ 2>/dev/null
ആ grep ലോക്കലായി എന്താണ് സെറ്റ് ചെയ്തിരിക്കുന്നതെന്നും വെണ്ടറുടെ സ്വതവേയുള്ള മൂല്യം എന്താണെന്നും പറയുന്നു. അഭാവവും വിവരമാണ്, അതിന്റെ അർത്ഥം കോമ്പൈൽ ചെയ്ത സ്വതവേയുള്ള മൂല്യം ബാധകമാണ് എന്നാണ്. അത് നിങ്ങളുടെ കുറിപ്പുകളിൽ എഴുതുക, അടുത്ത വ്യക്തിക്ക് അത് വീണ്ടും കണ്ടെത്തേണ്ടതില്ല.
നിയമവും അത് ചൂണ്ടിക്കാണിക്കുന്ന പട്ടികയും പ്രഖ്യാപിക്കുക
.network ഫയലിലെ നിയമം ഒരു പട്ടികയെ പേരിടുന്നു, ഒരു പേര് ചെയ്യുന്നത് അത്രമാത്രമാണ്. അത് ആ പട്ടികയ്ക്കുള്ളിലെ റൂട്ടുകൾ സൃഷ്ടിക്കുന്നില്ല, അവ അർത്ഥവത്താണോ എന്ന് പരിശോധിക്കുന്നുമില്ല. റൂട്ടുകളില്ലാതെ നിയമം പ്രഖ്യാപിച്ചാൽ ട്രാഫിക്കിനെ ഒത്തുനോക്കി പിന്നീട് ഉപേക്ഷിക്കുന്ന നയമാണ് ലഭിക്കുന്നത്.
അതേ ഫയലിൽ റൂട്ടുകൾ പ്രഖ്യാപിക്കുക, എത്തിച്ചേരാവുന്ന അടുത്ത ഹോപ്പുകളും ശരിയായ പട്ടികയും സഹിതം. പ്രഖ്യാപിച്ച നിയമത്തിൽ മുൻഗണന നിലനിർത്തുക, എന്നാൽ ക്രമീകരിച്ച പട്ടികയിൽ നിങ്ങൾ പ്രതീക്ഷിക്കുന്ന സ്ഥലത്ത് അത് ഇരിക്കും. ഉദ്ദേശിച്ചതിനേക്കാൾ മുമ്പ് തെറ്റായ പട്ടികയിൽ എത്തുന്ന നിയമം നിങ്ങൾ ശരിയാക്കാൻ ഉദ്ദേശിച്ച സേവനത്തേക്കാൾ കൂടുതൽ ട്രാഫിക് മാറ്റുന്നു. താഴെയുള്ള ഭാഗം പൂർണ്ണ ഫയലായല്ല, ഒരു രൂപമായി വായിക്കുക, കാരണം ഇന്റർഫേസ് ഉടമസ്ഥതയും ബന്ധത്തിന്റെ ബാക്കിയും ഇപ്പോഴും ഉണ്ടായിരിക്കണം.
[RoutingPolicyRule]
Family=ipv4
IPProtocol=tcp
SourcePort=443
Table=100
Priority=1000
[Route]
Destination=10.80.0.0/24
Gateway=10.80.0.1
Table=100
തുടർന്ന് വീണ്ടും ലോഡ് ചെയ്ത് ഫയലിനു പകരം കേർണൽ അവസ്ഥ വായിക്കുക. വൃത്തിയായി പാഴ്സ് ചെയ്ത കോൺഫിഗറേഷനും നിങ്ങൾ ഉദ്ദേശിക്കാത്ത ഒരു നിയമം സൃഷ്ടിച്ചേക്കാം, പ്രഖ്യാപനം പൂർണ്ണമായിരുന്നപ്പോൾ മാത്രമേ രണ്ടു കാഴ്ചകളും ഒത്തുപോകൂ.
ഇന്റർഫേസിന് ഒരു ഉടമയെ തിരഞ്ഞെടുക്കുക
ഒരു ടണലിൽ രണ്ട് മാനേജർമാർ രണ്ടിലും ബഗ് പോലെ തോന്നുന്ന ഒരു കലഹം സൃഷ്ടിക്കുന്നു. നിലവിലുള്ള wg-quick ക്രമീകരണം networkd-ലേക്ക് ഇറക്കുമതി ചെയ്യുന്നത് കൂട്ടിച്ചേർക്കലല്ല, കുടിയേറ്റമാണ്, രണ്ടും പ്രവർത്തിപ്പിച്ചാൽ ഇന്റർഫേസും അതിന്റെ നിയമങ്ങളും രണ്ട് ഉടമകൾക്ക് കീഴിൽ നിൽക്കും.
കുടിയേറ്റം ഒരൊറ്റ ഘട്ടത്തിൽ ചെയ്യുക: പഴയ യൂണിറ്റ് നിർത്തുക, പ്രവർത്തനരഹിതമാക്കുക, ഇന്റർഫേസും അതിന്റെ റൂട്ടുകളും networkd-ൽ പ്രഖ്യാപിക്കുക, പിന്നീട് വീണ്ടും ലോഡ് ചെയ്യുക. പഴയ യൂണിറ്റിന് ബൂട്ടിൽ തിരികെ വരാൻ കഴിയില്ലെന്ന് പരിശോധിക്കുക. റീബൂട്ടിനു ശേഷം വീണ്ടും സജീവമാകുന്ന ബാക്കി യൂണിറ്റ് നിങ്ങൾ ഇപ്പോൾ പ്രഖ്യാപിച്ച അവസ്ഥയ്ക്ക് മുകളിൽ എഴുതുന്നു. പുതിയത് ഒരു വീണ്ടും കണക്ഷനെ അതിജീവിക്കുന്നതുവരെ പഴയ കോൺഫിഗറേഷൻ ഫയൽ സൂക്ഷിക്കുക, പിന്നീട് അത് വിരമിക്കുക.
മാർക്കിന്റെ ഉടമസ്ഥതയ്ക്കും അതേ ശ്രദ്ധ വേണം: ഒരു നിയമം ഫയർവാൾ മാർക്കുമായി പൊരുത്തപ്പെടുന്നുവെങ്കിൽ, ആർക്കെങ്കിലും ആ മാർക്ക് സെറ്റ് ചെയ്യേണ്ടതുണ്ട്. ആരും സെറ്റ് ചെയ്യാത്ത മാർക്കിനെ പരാമർശിക്കുന്ന നിയമം ഉദ്ദേശ്യപൂർവ്വമെന്ന് തോന്നുന്ന ചത്ത കോൺഫിഗറേഷനാണ്.
ജീവിതചക്ര സംഭവങ്ങൾ പരിശീലിക്കുക
കോൺഫിഗറേഷൻ സംഭവങ്ങളിലുടനീളമുള്ള അതിന്റെ പെരുമാറ്റത്തോളം മാത്രമേ മൂല്യമുള്ളൂ. ലിങ്ക് താഴ്ത്തുക, ഉയർത്തുക, സേവനം വീണ്ടും ആരംഭിക്കുക, വിലാസം പുതുക്കുക. ഓരോന്നിനും ശേഷം നിയമങ്ങളുടെ പട്ടികയും പട്ടികയുടെ ഉള്ളടക്കവും വായിക്കുക.
sudo networkctl reload
ip rule show
ip route show table 100
sudo systemctl restart systemd-networkd
ഉദ്ദിഷ്ട ഫലം അതേ ഉടമസ്ഥതയുള്ള നയം വീണ്ടും സൃഷ്ടിക്കപ്പെടുകയും കാലഹരണപ്പെട്ട അവസ്ഥ വിരമിക്കുകയും ചെയ്യുക എന്നതാണ്, ഇത് ഓരോ വീണ്ടും കണക്ഷനു ശേഷവും ഷെൽ നിയമം വീണ്ടും ചേർക്കുന്നതിനേക്കാൾ ദീർഘകാലം നിലനിൽക്കും. മാറ്റരേഖയിൽ നിയമത്തിന്റെ ഉടമയായ ഫയലും അതിനെ പിന്തുണയ്ക്കുന്ന പതിപ്പും പേരിടുന്ന ഒരു വരി സൂക്ഷിക്കുക. അപ്പോൾ അടുത്ത എഞ്ചിനീയർക്ക് ഷെൽ ചരിത്രം കുത്തിവരയ്ക്കാതെ നയം കണ്ടെത്താം. ആരും ഉടമസ്ഥതയില്ലാത്ത നിയമം വീണ്ടും നഷ്ടപ്പെടുന്ന നിയമമാണ്.