ولې ستاسو OpenVPN کلاینټ د یو ځل وخت تېرېدو وروسته بند پاتې کیږي
هغه کلاینټ چې په لومړي وخت تېرېدو کې وځي، یو کوربه پریږدي چې آنلاین ښکاري او هېڅ نه وړي. د پروفایل اختیار او د بیا پیل کولو تګلاره جلا سم کړئ.
دوشنبه سهار: هغه تونل چې د جمعې په ورځ پورته شوی و، ورک شو، انټرفیس لا هم په لیست کې دی، او په ژورنال کې هېڅ نه لیکل شوي چې چا دا ولید۔ کوربه آنلاین دی، ډشبورډ شین دی، او هر هغه څه چې د اونۍ په پای کې یې ولېږل، د فزیکي انټرفیس له لارې بهر شو۔ دلته دوې خپلواکې پرېکړې ورکې دي: یوه دا چې ایا د کلاینټ پروسه د لنډمهاله ناکامۍ څخه ژغورل کیږي، او بله دا چې ایا د هغې پورتنۍ یوه څیز د پروسې له وتلو وروسته بیا پیلوي۔ یوازې یوه سمول بله تشه پرانیستې پریږدي۔
له هغه څه پیل وکړئ چې یونټ واقعاً کړي، نه له هغه څه چې څارنه یې ادعا کوي۔ systemctl status openvpn-client@office او journalctl -u openvpn-client@office -n 50 د وتلو لامل او هغه وروستۍ کرښه ښیي چې کلاینټ د تلو دمخه لیکلې وه۔
پروسه له دې مخکې ووتله چې چا ولیدله
هغه کلاینټ چې پرته له تېروتنې ورک شي، معمولاً په قصد وتلی وي۔ دا چلند پروفایل ټاکي، نه د خدمت مدیر: ping-exit پروسه هغه سمدلاسه پای ته رسوي چې بل لوري ځواب ورکول بند کړل، په داسې حال کې چې ping-restart پروسه ساتي او په دننه کې بیا نښلوي۔ د غونډې محدودیتونه او د بې فعاليت ټایمرونه له باندې هماغه انځور جوړوي: نه تونل او نه الارم۔
دوه ping لارښوونې په یو پروفایل کې یوځای نه شي کېدای، نو یوه وټاکئ او انتخاب ثبت کړئ۔ سرور ته هم وګورئ، ځکه چې د هغه خپل ping-exit د کلاینټ له غوښتنې پرته غونډه بندوي، او یوازې د سرور لاګ ثبتوي چې څوک دا پرېکړه کړې۔
د ping-exit او ping-restart ترمنځ انتخاب
د لپ ټاپ یا لرې سایټ لپاره چې باید ځان جوړ کړي ping-restart وټاکئ، او هغو حالتونو لپاره ping-exit وساتئ چې مړ تونل باید پروسه ودروي ترڅو بل څه پرې غبرګون وښيي۔ شمېرې د اړیکې په پرتله کم اهمیت لري: ping 10 د ping-restart 60 سره یوځای یعنی د ازموینې دمخه لس ثانیې او د بیا پیل دمخه شپېته ثانیې چوپتیا، چې په زیانمن موبایل لینک کې تېریزه او په تار لینک کې مناسبه ده۔ دلیل د کرښې ترڅنګ ولیکئ، که نه نو بل لوستونکی به فکر وکړي چې ډیفالټ ارزښتونه قصداً وو۔
بیا ډاډ ترلاسه کړئ چې واقعاً پروسه وه چې ووتله۔ هغه یونټ چې د مړ تونل په حال کې فعال راپور ورکوي بله ناکامي ده، چې لاندې بحث کیږي۔
هغه څارنه چې یونټ واقعاً بیا پیلوي
په systemd کوربه کې ترټولو کوچنی دوامدار بدلون یو drop-in فایل دی: Restart=on-failure او RestartSec=10 چې په /etc/systemd/system/[email protected]/restart.conf کې دي۔ drop-in یوازې هغه وخت لوستل کیږي چې systemd خپل تعریفونه بیا باروي، نو له هغې وروسته systemctl daemon-reload وچلوئ۔ د ارزښت د رسېدو په انګېرلو پرته د systemctl show -p Restart -p ExecMainStatus openvpn-client@office سره یې تایید کړئ۔ په فایل نوم کې انسټانس باید هغه پروفایل وي چې یونټ واقعاً یې باروي، نو د office لپاره لیکل شوی فایل د openvpn-client@home لپاره هېڅ نه کوي۔
on-failure یو حالت له پامه غورځوي: د صفر حالت سره پاک وتل۔ ځینې د ویجاړولو لارې همداسې پای ته رسي، نو د لارښود پاڼې له عبارت کلک باور پرته ثبت شوی حالت ولولئ۔ که ستاسو کلاینټ د صفر سره تسلیم شي، تاسو ته Restart=always ته اړتیا ده، او لګښت یې دا دی چې واقعاً خراب پروفایل تر هغو بیرته راځي چې د پیل کچې حد فعال شي او ژورنال ډک شي۔
Restart=always د قصد ودرولو وروسته هم فعالیږي۔ د ساتنې لپاره systemctl stop وکاروئ، او که یونټ باید ستاسو د کار پر مهال بند پاتې شي نو ماسک یې کړئ۔
هغه وخت چې تونل بند دی تېربېدل ونیسئ
څارنه تونل بیرته راوړي؛ دا نه شي کولای چې د تونل د نشتوالي پر مهال ترافیک بهر تلل بند کړي۔ persist-tun د بیا نښلولو ترمنځ وسیله او د هغې لارې ساتي، چې اسانه ده او یوه کړکۍ پرانیزي۔ وسیله پاتې کیږي، لارې لا هم هغې ته اشاره کوي، او پاکټونه پرته له ساتنې او پرته له راپور بهر بهیږي۔ دا د تګلارې انتخاب دی، نه بې طرفه ډیفالټ۔
کله چې کوربه باید هېڅکله بې ساتنې پاکټونه ونه لېږي، یوازې اوروال دی چې تضمین یې کولای شي۔ هغه د وتلو قاعده چې د تونل انټرفیس او د VPN سرور پته اجازه ورکوي او نور ټول غورځوي، د کلاینټ له مړینې وروسته هم پلي کیږي، او د کلاینټ په خپل ترتیباتو کې هېڅ داسې نه دی چې هغه ترافیک فلټر کړي چې کلاینټ یې نه وړي۔
دا د کلاینټ په قصد ودرولو سره وآزموئ۔ systemctl stop openvpn-client@office وچلوئ، بیا curl -m 5 https://example.com، چې د فزیکي لینک له لارې باید بریالي نه شي او په ناکامۍ پای ته ورسیږي۔ بریا یعنی د اوروال قاعده نشته یا ډېره اجازه ورکوونکې ده۔
بیا ونښلوئ، ډاډ ترلاسه کړئ چې تونل بیا ترافیک وړي، او یوازې بیا وروسته چک په څارنه کې اضافه کړئ۔ له cron څخه ip addr د tun وسیلې لپاره پوښتل ترټولو ډېره ناکامه څارنه ده، ځکه چې د persist-tun سره وسیله له غونډې اوږده ژوند کوي او چک روغتیا راپور ورکوي پداسې حال کې چې هېڅ نه وړل کیږي۔