systemd VPN സേവനം നിർത്തുന്നു: Type= ക്ലൈന്റുമായി ഒത്തുനോക്കുക

യൂണിറ്റുകൾ ശരിയായി തോന്നാം, systemctl start വിജയം റിപ്പോർട്ട് ചെയ്യാം, പത്ത് സെക്കൻഡിന് ശേഷം സേവനം നിഷ്ക്രിയമായി ഇരിക്കുന്നു. അല്ലെങ്കിൽ സ്റ്റാർട്ട് പരിധി നിർത്തുന്നതുവരെ ഓരോ അര മിനിറ്റിലും വീണ്ടും തുടങ്ങുന്നു. ഈ രണ്ട് സ്വഭാവങ്ങളും നെറ്റ്വർക്ക് തകരാറല്ല: യൂണിറ്റ് വിവരിക്കുന്ന പ്രക്രിയയുടെ ആയുസ്സ് ക്ലൈന്റ് യഥാർത്ഥത്തിൽ ചെയ്യുന്നതുമായി ഒത്തുപോകുന്നില്ല. ക്ലൈന്റ് ഫോർക്ക് ചെയ്ത് പുറത്തുപോകാം, അല്ലെങ്കിൽ സെഷൻ ക്രമീകരിച്ച് ഉടൻ പുറത്തുപോകാം.

വിജയകരമായ തുടക്കത്തിന് ശേഷം കുറച്ച് സെക്കൻഡിനുള്ളിൽ യൂണിറ്റ് നിഷ്ക്രിയമാകുന്നത് എന്തുകൊണ്ട്

systemd താൻ തുടങ്ങിയ പ്രക്രിയയിൽ നിന്നാണ് അവസ്ഥ അനുമാനിക്കുന്നത്, അതിനാൽ Type= ആ പ്രക്രിയയെക്കുറിച്ചുള്ള ഒരു വാദമാണ്, ഡോക്യുമെന്റേഷനല്ല. Type=simple ഉപയോഗിക്കുമ്പോൾ കമാൻഡ് പ്രവർത്തിക്കുന്നിടത്തോളം യൂണിറ്റ് സജീവമായി കണക്കാക്കപ്പെടുന്നു, അത് മടങ്ങുമ്പോൾ നിഷ്ക്രിയമാകുന്നു. അതിനാൽ കണക്ഷൻ ഒരു സഹായ പ്രോഗ്രാമിന് നൽകി പുറത്തുപോകുന്ന ക്ലൈന്റ് ടണൽ പ്രവർത്തിക്കുന്നുണ്ടെങ്കിലും ക്രാഷ് പോലെ തോന്നുന്നു. പിന്നീട് ജേണൽ തുടക്കവും നിർത്തലും ഉള്ള ഒരു മാതൃക കാണിക്കുന്നു, അത് കേടായ ബൈനറി പോലെ വായിക്കപ്പെടുന്നു.

നെറ്റ്വർക്ക് കോൺഫിഗറേഷൻ തൊടുന്നതിന് മുമ്പ് ക്ലൈന്റിന്റെ സ്വഭാവത്തിനൊപ്പം യൂണിറ്റിന്റെ തരം വായിക്കുക.

ക്ലൈന്റുമായി ഒത്തുപോകുന്ന തരം തിരഞ്ഞെടുക്കുക

രണ്ട് മാതൃകകൾ മിക്ക വെണ്ടർ CLI-കളെയും ഉൾക്കൊള്ളുന്നു: സെഷൻ ക്രമീകരിച്ച് പുറത്തുപോകുന്ന കമാൻഡ്, മടങ്ങുന്നതിന് മുമ്പ് സഹായിയെ ഫോർക്ക് ചെയ്യുന്ന കമാൻഡ്. ഓരോന്നിനും വ്യത്യസ്ത യൂണിറ്റ് രൂപം വേണം.

[Service]
Type=oneshot
RemainAfterExit=true
ExecStart=/usr/bin/protonvpn-cli connect -f
ExecStop=/usr/bin/protonvpn-cli disconnect

oneshot ഒപ്പം RemainAfterExit=true ചേരുമ്പോൾ കമാൻഡ് മടങ്ങിയതിന് ശേഷവും യൂണിറ്റ് സജീവമായി നിലനിൽക്കുന്നു, ഇത് ക്രമീകരിച്ച് പുറത്തുപോകുക മാതൃകയുമായി ഒത്തുപോകുന്നു, കൂടാതെ നിർത്തൽ കമാൻഡ് സേവനത്തിന് വൃത്തിയായ അടയ്ക്കൽ നൽകുന്നു. ഫോർക്ക് ചെയ്യുന്ന ക്ലൈന്റ് അതേ രൂപം നിലനിർത്തുന്നു, പക്ഷേ systemd കുട്ടിയെ പിന്തുടരാൻ Type=forking വേണം. Restart=on-failure, RestartSec=30, പരിമിതമായ StartLimitBurst എന്നിവ സജ്ജമാക്കുക, ദാതാവിന്റെ തടസ്സം പിശക് മൂടുന്ന റീസ്റ്റാർട്ട് ലൂപ്പായി മാറാതിരിക്കാൻ.

മേൽനോട്ടത്തിലുള്ള ക്ലൈന്റിനെ ഒരിക്കലും ഡീമൺ ആകാൻ അനുവദിക്കരുത്

systemd-ന് പുറത്തുള്ള മേൽനോട്ടക്കാർ അതേ ചുമരിൽ ഇടിക്കുന്നു. ഡീമൺ ആയ ക്ലൈന്റ് തുടങ്ങുന്ന runit റൺ സ്ക്രിപ്റ്റ് ഉടൻ മേൽനോട്ടക്കാരനിലേക്ക് മടങ്ങുന്നു, അയാൾ ആ മടക്കം ക്രാഷ് എന്ന് വായിച്ച് മറ്റൊരു പകർപ്പ് തുടങ്ങുന്നു. ഓരോ മേൽനോട്ടക്കാരനും മുൻപന്തിയിലെ പ്രക്രിയ കൈവശം വയ്ക്കാൻ പ്രതീക്ഷിക്കുന്നു, sshd -D മുന്നിൽ നിൽക്കുന്നതുപോലെ. മേൽനോട്ടത്തിലുള്ള കമാൻഡുകൾക്ക് ഡീമൺ ഫ്ലാഗ് എടുത്തുകളയുക, പിന്നണി ജോലി മേൽനോട്ടക്കാരന് വിടുക. ടണൽ ഉണ്ടാകുന്നതിന് മുമ്പ് മടങ്ങുന്ന റാപ്പർ സ്ക്രിപ്റ്റുകളും അതേ ആശയക്കുഴപ്പം ഉണ്ടാക്കുന്നു.

തന്നെത്താൻ വേർപെടുത്തുന്ന പ്രക്രിയ അതിനെ നിരീക്ഷിക്കേണ്ടിയിരുന്ന എല്ലാത്തിനും അദൃശ്യമാണ്.

സെഷൻ അവസാനിക്കുന്നു, ടണലും കൂടെ കൊണ്ടുപോകുന്നു

ഡെസ്ക്ടോപ്പ് സെഷൻ താൻ തുടങ്ങുന്ന ക്ലൈന്റിന്റെ ഉടമയാണ്. ലോഗിൻ അവസാനിപ്പിക്കുക, സെഷൻ ബസ് അപ്രത്യക്ഷമാകുന്നു, ടണലും കൂടെ കൊണ്ടുപോകുന്നു, അവസാന വിൻഡോ അടയ്ക്കുമ്പോൾ ഗ്രാഫിക്കൽ ക്ലൈന്റിന്റെ കണക്ഷൻ പലപ്പോഴും വിട്ടുപോകുന്നതിന്റെ കാരണം ഇതാണ്. സർവറുകൾ സ്വയം ഉയരുന്ന സിസ്റ്റം യൂണിറ്റോ NetworkManager പ്രൊഫൈലോ ഉപയോഗിക്കണം. ടണൽ ലോഗിനോടൊപ്പം അവസാനിക്കേണ്ടതുണ്ടെങ്കിൽ മാത്രമേ ഉപയോക്തൃ യൂണിറ്റിന് അർത്ഥമുള്ളൂ, അതിനാൽ അതിനെ ഗ്രാഫിക്കൽ സെഷൻ ലക്ഷ്യവുമായി ബന്ധിപ്പിച്ച് അത് വിവരണത്തിൽ പറയുക.

സേവന ഉപയോക്താവ് അതே പ്രശ്നത്തിന്റെ മറ്റേ പകുതിയാണ്. root ഉടമസ്ഥതയിലുള്ളതും മോഡ് 0600 ഉള്ളതുമായ ഒരു കീ മറ്റൊരു അക്കൗണ്ടിൽ പ്രവർത്തിക്കുന്ന യൂണിറ്റിന് വായിക്കാനാവില്ല, നിങ്ങളുടെ ഷെല്ലിൽ sudo എന്ത് നേടിയാലും.

systemctl cat openvpn-server@work
sudo chown -R openvpn:network /etc/openvpn/server
sudo find /etc/openvpn -type f -perm /077 -ls

വിലാസം ഉണ്ടായതിന് ശേഷം ആശ്രിതങ്ങളെ ക്രമീകരിക്കുക

ഇതുവരെ സൃഷ്ടിക്കാത്ത ടണൽ വിലാസത്തിലേക്ക് ഡീമൺ ബന്ധിപ്പിക്കുമ്പോൾ, അത് Cannot assign requested address നൽകി പുറത്തുപോകുന്നു. പരിഹാരം വീണ്ടും ശ്രമിക്കുന്ന ലൂപ്പല്ല, വ്യക്തമായ ക്രമീകരണമാണ്.

[Unit]
After=network.target [email protected]
Requires=sys-devices-virtual-net-wg0.device

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

പിന്നീട് ഒരിക്കൽ റീബൂട്ട് ചെയ്ത്, ടണൽ ഉപകരണം പ്രത്യക്ഷപ്പെട്ടതിന് ശേഷം യൂണിറ്റ് സജീവമാണെന്ന് ഉറപ്പാക്കുക. systemctl start കൊണ്ട് മാത്രം പരിശോധിച്ച പരിഹാരം ശരിയാക്കേണ്ടിയിരുന്ന ബൂട്ട് ക്രമം പരീക്ഷിച്ചിട്ടില്ല.