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 સાથે કમાન્ડ પાછું આવ્યા પછી પણ યુનિટ સક્રિય રહે છે, જે ગોઠવો-અને-નીકળો પેટર્ન સાથે મેળ ખાય છે, અને સ્ટોપ કમાન્ડ સેવાને સ્વચ્છ બંધ કરે છે. ફોર્ક કરતો ક્લાયન્ટ એ જ આકાર રાખે છે પણ તેને Type=forking જોઈએ જેથી systemd સંતાનને અનુસરે. 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 થી ચકાસાયેલો સુધારો બૂટ ક્રમની કસોટી કરી નથી જે તેને સુધારવાનો હતો.