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 سره تایید شوی، هغه د پیل ترتیب نه دی ازمویلی چې باید سم یې کړې وای۔