ബൂട്ട് സമയത്ത് ഒരു നിശ്ചിത VPN വിലാസം ബന്ധിക്കുന്ന സോക്കറ്റ് യൂണിറ്റ്, ടണൽ അത് അനുവദിക്കുന്നതിന് മുൻപേ പരാജയപ്പെടാം, അതിന് പിന്നിലെ സേവനം ഒരിക്കലും ആരംഭിക്കുന്നുമില്ല. രണ്ട് സ്വിച്ചുകൾ പരിഹാരങ്ങളായി തോന്നുന്നു, ആ പ്രശ്നത്തിന്റെ വ്യത്യസ്ത പകുതികൾ പരിഹരിക്കുന്നു. വിലാസം ഇപ്പോഴും ഇല്ലാത്തപ്പോൾ തന്നെ FreeBind systemd-ന് ശ്രോതാവിനെ സൃഷ്ടിക്കാൻ അനുവദിക്കുന്നു. After= ജോലികൾ ക്രമീകരിക്കുന്നു മാത്രം, അതിനാൽ കാര്യങ്ങൾ എപ്പോൾ ആരംഭിക്കുന്നു എന്നത് മാറ്റുന്നു, വിലാസം നേരത്തെ എത്തിക്കുന്നില്ല.

രണ്ട് വ്യത്യസ്ത പ്രശ്നങ്ങൾ, രണ്ട് വ്യത്യസ്ത സ്വിച്ചുകൾ

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

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

FreeBind: വിലാസത്തിന് മുൻപേ ശ്രോതാവ്

FreeBind കെർണലിനോട് സ്ഥലീയമല്ലാത്ത വിലാസത്തിലേക്ക് ബന്ധിക്കാൻ അനുവദിക്കാൻ പറയുന്നു, അതിനാൽ systemd ബൂട്ട് സമയത്ത് കേൾക്കുന്ന സോക്കറ്റ് സൃഷ്ടിച്ച്, അപ്ലിക്കേഷൻ ആരംഭിക്കുമ്പോഴെല്ലാം അത് അപ്ലിക്കേഷന് നൽകാം. സോക്കറ്റ് സജീവീകരണത്തിന്റെ ഉദ്ദേശ്യം ഇതാണ്, സോക്കറ്റിന് അതിന് പിന്നിലെ സേവനത്തെക്കാൾ കൂടുതൽ കാലം നിലനിൽക്കാൻ കഴിയുന്നതിന്റെ കാരണവും ഇതാണ്.

[Socket]
ListenStream=
ListenStream=10.8.0.1:8443
FreeBind=yes

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

systemd സോക്കറ്റ് റഫറൻസ് ഈ ഓപ്ഷന്റെ പിന്നിലെ IPv4, IPv6 സ്വഭാവം രേഖപ്പെടുത്തുന്നു, പ്രധാന വിശദാംശം അത് ബന്ധനത്തിനാണ്, റൂട്ടിംഗിനല്ല എന്നതാണ്. അതിൽ ഒന്നും വിലാസം അനുവദിക്കുന്നില്ല, VPN ആരംഭിക്കുന്നുമില്ല. FreeBind ശ്രോതാവിന് നൽകുന്ന അനുമതിയാണ്, ഇന്റർഫേസിന്റെ പകരമല്ല.

After=, Wants=: ക്രമം സന്നദ്ധതയല്ല

ക്രമവും ആവശ്യകതയും വേറിട്ട അക്ഷങ്ങളാണ്, അവ കലർത്തുന്നത് ശരിയായ ക്രമത്തിൽ ആരംഭിച്ചിട്ടും പരാജയപ്പെടുന്ന യൂണിറ്റുകൾ സൃഷ്ടിക്കുന്നു. After=vpn-client.service എന്നത്, രണ്ട് ജോലികളും ആരംഭിച്ചാൽ ഇത് മറ്റേതിന്റെ ആരംഭത്തിനായി കാത്തിരിക്കുന്നു എന്ന് മാത്രം അർത്ഥമാക്കുന്നു. അത് VPN-നെ വലിച്ചിടുന്നില്ല, VPN ബന്ധനം പൂർത്തിയാക്കുന്നതിനും കാത്തിരിക്കുന്നില്ല.

Wants=, Requires= പോലുള്ള ആവശ്യകതാ നിർദ്ദേശങ്ങൾ സജീവീകരണം കൈകാര്യം ചെയ്യുന്നു, ആശ്രിതത്വം പരാജയപ്പെടുമ്പോൾ എന്ത് സംഭവിക്കുന്നു എന്നതിൽ വ്യത്യാസപ്പെടുന്നു: ഒന്ന് തുടരുന്നു, മറ്റൊന്ന് നിലയ്ക്കുന്നു. ബന്ധിത ടണൽ എന്നതിന്റെ അർത്ഥം രണ്ടിനും അറിയില്ല. VPN പ്രക്രിയ വിലാസം അനുവദിക്കാതെയും സജീവമാകാം, വിലാസം അനുവദിച്ച് സഹപ്രവർത്തകനിലേക്ക് റൂട്ട് ഇല്ലാതെയും ആകാം, രണ്ട് അവസ്ഥകളും ആശ്രിതത്വം പൂർത്തീകരിക്കുന്നു. അപ്ലിക്കേഷന് വിലാസം നിലവിലുണ്ടാകണമെങ്കിൽ, പ്രക്രിയ ആരംഭിച്ചതിനെ സന്നദ്ധതയുടെ തെളിവായി കാണുന്നതിന് പകരം ആ വ്യവസ്ഥ വ്യക്തമായി മാതൃകയാക്കുക.

systemctl cat, systemctl show -p After -p Wants -p Requires ഉപയോഗിച്ച് യൂണിറ്റ് യഥാർത്ഥത്തിൽ എന്ത് പ്രഖ്യാപിക്കുന്നു എന്ന് പരിശോധിക്കുക. മൂന്ന് വ്യത്യസ്ത ഡയറക്ടറികളിലെ drop-in നിങ്ങൾ ഒരിക്കലും എഴുതാത്ത നിർദ്ദേശങ്ങൾ ചേർത്തേക്കാം, systemd ഫലപ്രദമായ യൂണിറ്റ് മാത്രം വായിക്കുന്നു.

network-online.target ചെയ്യാത്തത്

network-online.target-ന് ശേഷം ക്രമീകരിച്ച യൂണിറ്റ്, നെറ്റ്വർക്ക് മാനേജർ നെറ്റ്വർക്ക് ഉപയോഗയോഗ്യമെന്ന് പ്രഖ്യാപിക്കുന്നതിനായി കാത്തിരിക്കുന്നു, ഇത് ബൂട്ട് സമയത്തെ സമന്വയ കേന്ദ്രമാണ്, തുടർച്ചയായ വ്യവസ്ഥയല്ല. ഒരു നിർദ്ദിഷ്ട ടണൽ ഉയർന്നിട്ടുണ്ടോ എന്ന് അത് പറയുന്നില്ല, ഉച്ചയ്ക്ക് ശേഷം VPN വീണ്ടും ബന്ധിപ്പിക്കുമ്പോൾ അത് വീണ്ടും പ്രവർത്തിക്കുകയുമില്ല. അതിനെ പുനർബന്ധന മോണിറ്ററായി കാണുന്നതാണ് ആ ലക്ഷ്യത്തിന്റെ ഏറ്റവും സാധാരണമായ തെറ്റായ വായന.

systemd പ്രോജക്ട് ആ വ്യത്യാസം നേരിട്ട് രേഖപ്പെടുത്തുന്നു, പ്രായോഗിക അനന്തരഫലം ടണൽ വിലാസം ആവശ്യമുള്ള എല്ലാത്തിനും ആശ്രിതത്വം സ്വയം സ്വന്തമായിരിക്കണം എന്നതാണ്. network-online-നായി കാത്തിരുന്ന് പിന്നീട് ടണൽ വിലാസം ബന്ധിക്കുന്ന യൂണിറ്റ്, ടണൽ യാദൃച്ഛികമായി ആദ്യം ഉയരുമ്പോൾ മാത്രമാണ് ശരി, അത് യാദൃച്ഛികതയാണ്, രൂപകൽപ്പനയല്ല.

നിങ്ങൾ യഥാർത്ഥത്തിൽ തിരഞ്ഞെടുത്ത ജീവിതചക്രം പരിശോധിക്കുക

ശുദ്ധമായ ബൂട്ട്, വിലാസം പ്രത്യക്ഷപ്പെട്ടതിന് ശേഷമുള്ള അഭ്യർത്ഥന, VPN വീണ് തിരികെ വന്നതിന് ശേഷമുള്ള സ്വഭാവം എന്നിവ പരിശോധിക്കുക. ആ മൂന്ന് കേസുകൾ പ്രവർത്തിക്കുന്ന ശ്രോതാവിനെ പ്രവർത്തിക്കുന്ന സേവനത്തിൽ നിന്ന് വേർതിരിക്കുന്നു.

systemd-analyze verify myapp.socket
systemctl cat myapp.socket
ss -ltn "sport = :8443"

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

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

അനുബന്ധ ലേഖനങ്ങൾ