OpenVPN up-ൽ സേവനം പുനരാരംഭിക്കൽ: ഹുക്കുകൾ tun0.device-നേക്കാൾ മികച്ചത്

ആശ്രിത സേവനത്തെ tun0.device ലേക്ക് ബന്ധിപ്പിക്കുന്നത് ടണലിന് സബ്സ്ക്രൈബ് ചെയ്യുന്നതുപോലെ തോന്നുന്നു, പക്ഷേ അങ്ങനെയല്ല. ഡിവൈസ് യൂണിറ്റ് ഇന്റർഫേസ് നിലവിലുണ്ടെന്ന് പ്രതിഫലിപ്പിക്കുന്നു, അത് പരാജയപ്പെട്ട കണക്ഷനിലും തുടർന്നുള്ള പുനഃബന്ധനത്തിലും ശരിയായി തുടരാം. അപ്പോൾ സേവനം തെറ്റായ നിമിഷത്തിൽ പ്രവർത്തിക്കുന്നു, അല്ലെങ്കിൽ ഒരിക്കലും ഇല്ല, ഇന്റർഫേസ് ഇടയിൽ അപ്രത്യക്ഷമായോ എന്നതിനെ ആശ്രയിച്ച്. നിങ്ങൾക്ക് യഥാർത്ഥത്തിൽ പ്രധാനമായ ഇവന്റ് വിവരിക്കുന്ന ഹുക്ക് OpenVPN വിളിക്കുന്നതാണ്, systemd അനുമാനിക്കുന്നതല്ല.

ട്രിഗർ തിരഞ്ഞെടുക്കുന്നതിന് മുമ്പ് സേവനത്തിന് ഏത് വ്യവസ്ഥ വേണമെന്ന് തീരുമാനിക്കുക, കാരണം മൂന്ന് സ്ഥാനാർത്ഥികളും പരസ്പരം മാറ്റാൻ കഴിയുന്നവയല്ല.

ഡിവൈസ് യൂണിറ്റ് യഥാർത്ഥത്തിൽ എന്താണ് ട്രാക്ക് ചെയ്യുന്നത്

systemd നെറ്റ്വർക്ക് ഇന്റർഫേസിനെക്കുറിച്ചുള്ള കെർണലിന്റെ കാഴ്ചയിൽ നിന്ന് ഡിവൈസ് യൂണിറ്റ് സൃഷ്ടിക്കുന്നു, അതിനാൽ ഇന്റർഫേസ് പ്രത്യക്ഷപ്പെടുമ്പോൾ tun0.device സജീവമാകുന്നു, നീക്കം ചെയ്യുമ്പോൾ നിഷ്ക്രിയമാകുന്നു. persist-tun ഉപയോഗിച്ചാൽ, മൃദുവായ പുനരാരംഭം ഇന്റർഫേസ് അതിന്റെ സ്ഥാനത്ത് നിലനിർത്തുന്നു, അതിനാൽ യൂണിറ്റ് ഒരിക്കലും ഫ്ലാപ്പ് ചെയ്യുന്നില്ല, അതിനോട് ബന്ധിപ്പിച്ച ഒന്നും ട്രിഗർ ചെയ്യുന്നുമില്ല. സ്ഥിരതയില്ലാതെയും, യൂണിറ്റ് റൂട്ടുകൾ, DNS അല്ലെങ്കിൽ ദൂരെയുള്ള അറ്റം പ്രതികരിക്കുന്നുണ്ടോ എന്നതിനെക്കുറിച്ച് ഒന്നും പറയുന്നില്ല.

അത് അതിനെ 'VPN തയ്യാറാണ്' എന്നതിന് മോശം പകരക്കാരനാക്കുന്നു. പ്രാദേശിക വിലാസം മാത്രം ആവശ്യമുള്ള ശ്രോതാവിന് ഇന്റർഫേസിന്റെ നിലനിൽപ്പ് മതിയായേക്കാം, എന്നാൽ ദൂരെയുള്ള നെറ്റ്വർക്കിലെ ആപ്ലിക്കേഷനെ വിളിക്കുന്ന സേവനത്തിന് റൂട്ടുകളും എത്തിച്ചേരാനുള്ള കഴിവും വേണം, അത് ഡിവൈസ് യൂണിറ്റിന് പ്രകടിപ്പിക്കാനാവില്ല.

up, route-up, up-restart എന്നിവ വ്യത്യസ്ത അർത്ഥങ്ങളാണ്

TUN/TAP ഉപകരണം തുറന്ന് ഇന്റർഫേസ് കോൺഫിഗർ ചെയ്തതിന് ശേഷം up പ്രവർത്തിക്കുന്നു, അത് അനുവദിച്ച വിലാസം ബൈൻഡ് ചെയ്യുന്ന ശ്രോതാവിന് ശരിയായ നിമിഷമാണ്. റൂട്ടുകൾ ഇൻസ്റ്റാൾ ചെയ്തതിന് ശേഷം, കോൺഫിഗർ ചെയ്ത റൂട്ട് കാലതാമസത്തിന് വിധേയമായി route-up പ്രവർത്തിക്കുന്നു, റൂട്ട് ഘട്ടം പൂർത്തിയാകേണ്ട ജോലിക്ക് അനുയോജ്യമാണ്. രണ്ടും ദൂരെയുള്ള ആപ്ലിക്കേഷൻ പ്രതികരിക്കുന്നുവെന്ന് തെളിയിക്കുന്നില്ല. അവയ്ക്കിടയിൽ തിരഞ്ഞെടുക്കുന്നത് സേവനത്തിന് എന്ത് വേണം എന്ന ചോദ്യമാണ്, ഏത് ഹുക്ക് കൂടുതൽ പൂർണ്ണമായി തോന്നുന്നു എന്നതല്ല.

persist-tun ഉപയോഗിച്ച്, പുനരാരംഭങ്ങൾ ഉപകരണം വീണ്ടും ഉപയോഗിക്കുന്നു, അതിനാൽ up-restart സെറ്റ് ചെയ്തിട്ടില്ലെങ്കിൽ up വീണ്ടും പ്രവർത്തിക്കുന്നില്ല. ആ ഓപ്ഷൻ രേഖപ്പെടുത്തിയ പുനരാരംഭ ജീവിതചക്രത്തിന് up സ്ക്രിപ്റ്റ് പ്രവർത്തനക്ഷമമാക്കുന്നു, അതിന്റെ പരിസ്ഥിതി ആദ്യ സ്റ്റാർട്ടുമായി താരതമ്യപ്പെടുത്തുമ്പോൾ കുറയ്ക്കപ്പെട്ടതാണ്. പൂർണ്ണ പരിസ്ഥിതി അനുമാനിക്കുന്ന സ്ക്രിപ്റ്റ് ആദ്യ കണക്ഷനിൽ പ്രവർത്തിക്കുകയും അടുത്തതിൽ പരാജയപ്പെടുകയും ചെയ്യുന്നു.

പ്രവർത്തനം കാത്തിരിക്കാതെ അയക്കുക

systemctl restart സമകാലികമായി വിളിക്കുന്ന ഹുക്ക്, അതിന്റെ ക്രമം ടണലിനായി കാത്തിരിക്കുന്ന യൂണിറ്റിനോട് ഡെഡ്ലോക്ക് ആകാം. systemctl --no-block try-restart vpn-dependent.service ജോലി ക്യൂവിൽ ഇട്ട് മടങ്ങുന്നു, അത് ഹുക്ക് താൻ പ്രതികരിച്ചിരുന്ന കണക്ഷൻ ബ്ലോക്ക് ചെയ്യുന്നത് തടയുന്നു. try-restart പ്രവർത്തിക്കുന്ന യൂണിറ്റിൽ മാത്രം പ്രവർത്തിക്കുന്നു, അതേസമയം restart നിഷ്ക്രിയ യൂണിറ്റും ആരംഭിക്കുന്നു; ശീലത്തിൽ നിന്നല്ല, ബോധപൂർവം തിരഞ്ഞെടുക്കുക.

ക്യൂവിൽ ഇടുന്നത് പരിശോധനയല്ല. ജോലി സ്വീകരിച്ച ഉടൻ ഹുക്ക് വിജയം തിരികെ നൽകുന്നു, അതിനാൽ പരിശോധന ലക്ഷ്യ യൂണിറ്റിന്റെ ജേണലിലോ അതിന്റെ യഥാർത്ഥ ശ്രോതാവ് അവസ്ഥയിലോ നടക്കണം.

പുനരാരംഭ നയം യൂണിറ്റിലാണ്, ഹുക്കിലല്ല

RemainAfterExit=yes ഉള്ള oneshot യൂണിറ്റ് അതിന്റെ കമാൻഡ് പുറത്തുപോയതിന് ശേഷവും സജീവമായി തുടരുന്നു, രണ്ടാം സ്റ്റാർട്ട് അഭ്യർത്ഥന ഒന്നും ചെയ്യുന്നില്ല, കാരണം systemd അത് ഇതിനകം ആരംഭിച്ചതായി കണക്കാക്കുന്നു. ഇത് ചുറ്റും രൂപകൽപ്പന ചെയ്യേണ്ട ഒരു സ്വഭാവമാണ്, ആവർത്തിച്ചുള്ള സ്റ്റാർട്ട് വിളികളിലൂടെ ഒഴിവാക്കേണ്ട ഒരു കുറ്റമല്ല. പ്രവർത്തനം ഓരോ കണക്ഷനിലും പ്രവർത്തിക്കണമെങ്കിൽ, യൂണിറ്റിന് അത് അനുവദിക്കുന്ന ഒരു രൂപം വേണം.

After= യൂണിറ്റുകളെ ക്രമീകരിക്കുന്നു, BindsTo= ജീവിതകാലങ്ങളെ ബന്ധിപ്പിക്കുന്നു, പക്ഷേ രണ്ടും 'VPN വീണ്ടും കണക്ട് ചെയ്യുമ്പോഴെല്ലാം ഇത് പുനരാരംഭിക്കുക' എന്ന് അർത്ഥമാക്കുന്നില്ല. ടണലിനോട് ബന്ധിപ്പിച്ച യൂണിറ്റ് ടണൽ നിൽക്കുമ്പോൾ നിൽക്കുന്നു; ടണൽ തിരികെ വരുമ്പോൾ, എന്തെങ്കിലും അതിനെ വീണ്ടും ആരംഭിക്കുന്നില്ലെങ്കിൽ, അത് സ്വയം പുനരാരംഭിക്കുന്നില്ല.

ഒന്നല്ല, മൂന്ന് പുനഃബന്ധനങ്ങൾ പരീക്ഷിക്കുക

കോൾഡ് ബൂട്ട്, പൂർണ്ണ ക്ലയന്റ് പുനരാരംഭം, മൃദു പുനഃബന്ധനം എന്നിവ ഓരോന്നും വ്യത്യസ്ത പാത പരിശീലിക്കുന്നു. മൃദു പുനഃബന്ധനമാണ് കാണാതായ up-restart, കുറയ്ക്കപ്പെട്ട പരിസ്ഥിതി, അല്ലെങ്കിൽ ഒരിക്കലും നിഷ്ക്രിയമാകാത്ത ഡിവൈസ് യൂണിറ്റ് വെളിപ്പെടുത്തുന്നത്. മൂന്നും പ്രവർത്തിപ്പിച്ച് രണ്ട് ദിശകളും സ്ഥിരീകരിക്കുക: ടണൽ ഉയരുമ്പോൾ സേവനം പ്രവർത്തിക്കുന്നു, Wi-Fi റോമിംഗ് പോലുള്ള അസംബന്ധമായ ലിങ്ക് മാറ്റങ്ങളിൽ അത് പുനരാരംഭിക്കുന്നുമില്ല.

ആശ്രിത സേവനം നിങ്ങളുടെ സ്വന്തം അഡ്മിനിസ്ട്രേറ്റീവ് ആക്സസ് വഹിക്കുമ്പോൾ സ്വതന്ത്രമായ വീണ്ടെടുപ്പ് പാത സൂക്ഷിക്കുക. നിങ്ങൾ ബന്ധിപ്പിച്ചിരിക്കുന്ന കാര്യം പുനരാരംഭിക്കുന്ന ഹുക്ക് നിങ്ങളെ പുറത്ത് പൂട്ടിയിടാൻ കഴിയുന്ന മാറ്റമാണ്.