آیا د قلاب سکریپټ د تونل بل لوري ته رسېږي، دا په درې شرطونو پورې اړه لري: کومې پېښې سره تړلی دی، آیا د سکریپټ د چلېدو پر مهال OpenVPN لا هم د خپل پیل په ترتیب کې دی، او آیا کار له هغه ترتیب څخه جلا شوی دی۔ ډېری سکریپټونه په درېیم کې ناکامېږي۔ د خوب اضافه کول د ژوند دورې ستونزه د وخت ستونزه ګڼي، او یوازې دومره ځله کار کوي چې ګمراه کړي۔

لومړی پېښه وټاکئ، بیا د کار ځنډولو میکانیزم، بیا هغه ځای چې ځنډول شوی کار پکې چلېږي۔ دا درې پرېکړې خپلواکې دي، او د هغوی ګډول همدا هغه څه دي چې دوه کرښې قلاب یوه ټوله ماسپښین جوړوي۔

ولې قلاب د هغه تونل انتظار کوي چې هغه يې انتظار کوي

OpenVPN خپل قلابونه په همغږي ډول رابولي، د هغه هماغه بهیر په دننه کې چې پاکټونه ګرځوي۔ up هغه وخت فعالېږي چې tun یا tap وسیله شتون ولري خو تر هغه مخکې چې کومه لار اضافه شي، او route-up د لارو وروسته فعالېږي؛ د دغو دواړو شیبو څخه هېڅ یو هم دا ژمنه نه کوي چې بل لوری به ځواب ووايي۔ تر هغه چې د کوم قلاب سکریپټ لا هم چلېږي، ډیمون مخته نه شي کولی، نو هغه حکم چې تمه لري ټرافیک د تونل له لارې تېر شي د هغه تونل انتظار کوي چې د هغه حکم انتظار کوي۔ همدا ګرد انتظار هغه لامل دی چې لاسي چلول بریالي کېږي او قلاب وخت تېرېږي۔

ښکاره حل، یعنې څو ثانیې خوب، کله ناکله کار کوي ځکه چې لرې پای پخپله پورته شو، نه ځکه چې خوب څه سم کړل۔ هغه مرستندوی چې د تیارۍ پوښتنه کوي بل ځواب دی: قلاب بېرته راځي، لېږد پیلېږي، او مرستندوی هغه څه ترلاسه کوي چې ورته اړتیا لري کله چې هغه واقعاً هلته وي۔

قلاب د اسانتیا نه، د پېښې له مخې وټاکئ

up هغه کار سره وتړئ چې یوازې وسیلې ته اړتیا لري، route-up هغه کار سره چې لارو ته اړتیا لري، او client-connect او client-disconnect وساتئ د سرور په لوري د هر پیرودونکي دندو لپاره۔ د نښلونې په پرې کېدو کې پاکول باید دوه ځله چلېدو ته زغم ولري، ځکه چې د دوامداره برخې له لارې بیا نښلول د بشپړ بیا پیل په څېر ترتیب نه تعقیبوي۔ په سرور کې، client-connect هغه وخت فعالېږي چې پیرودونکی تصدیق کوي نه هغه وخت چې ډیمون پیلېږي، چې د منطق هلته لېږدولو دمخه یې تاییدول ارزښت لري۔ که کار د یوې اړیکې پر ځای د خدمت د ژوند دورې پورې اړه ولري، systemd واحد تر هر قلاب ښه کور دی۔

د قلاب حکمونه ډیمون مستقیم اجرا کوي، پرته له منځګړي شیل، نو ifconfig_remote په up کرښه کې د لفظي متن په توګه راروان شي۔ حکم په څرګند شیل کې ونغښتئ، یا منطق په هغه سکریپټ کې وساتئ چې چاپېریال لولي۔ ipchange یو لارښود دی چې خپل دلیلونه ورزیاتوي: هغه حکم ته پته او پورټ ورکوي، نو هغه سکریپټ چې د هېچا لپاره نه دی لیکل شوی دوه ناڅاپي دلیلونه ویني۔

د کار جلا کولو درې لارې

لومړی انتخاب دا دی چې مرستندوی د قلاب له داخل څخه شاتګ ته ولېږئ: هغه د setsid یا systemd-run --scope سره پیل کړئ، میراثي ښودونکي وتړئ، او سمدلاسه له صفر سره ووځئ۔ دویم دا چې قلاب یو کوچنی حالت فایل ولیکي او systemd ټایمر یا د لارې واحد پر هغه عمل وکړي، چې قلاب ساده ساتي او د بیا هڅې پالیسي هلته ږدي چې لاګونه پکې دي۔ درېیم دا چې قلاب په بشپړه توګه پرېږدئ او کار ته د VPN خدمت وروسته ترتیب شوې واحد ته یوسئ، چې هغه وخت سم ځواب دی چې کار په هېڅ ډول د هرې اړیکې نه وي۔ درېواړه یو قاعده شریکوي: قلاب باید د تونل له اړتیا دمخه بېرته راشي۔

هر څه چې وټاکئ، مرستندوی دوه ځله اجرا کېدونکی او کتنې وړ کړئ۔ دوه پوښل شوي غوښتنې باید یو ناګرځېدونکی عمل دوه ځله اجرا نه کړي، او ناکام مرستندوی باید یو څه پرېږدي چې انسان یې لولي۔

د سندباکس ناکامۍ د ژوند دورې ناکامیو څخه جلا کړئ

کله چې سکریپټ د root له موجې څخه چلېږي او د خدمت په توګه ناکامېږي، لامل معمولاً شبکه نه بلکې سندباکس وي۔ محدودوونکی ProtectHome، یوازې لوستلو وړ ProtectSystem، یا هغه کاري ډایرکټري چې شتون نه لري کولی شي سکریپټ یا د هغه ډاټا بې لاسرسي کړي، او په SELinux کوربه کې فایل ته هم داسې شرایط ته اړتیا وي چې اجرا اجازه ورکړي۔ واحد د systemctl cat openvpn-server@server سره او ژورنال د journalctl -u openvpn-server@server -n 80 سره ولولئ، بیا د اړیکې وخت تېرېدو پر ځای د اجازې یا شرایطو تېروتنه ولټوئ۔ سندباکس غیر فعالول باید لومړی نه، بلکې وروستی ګام وي۔

د ژوند دورې ناکامي بېل ښکاري: قلاب پیلېږي، مرستندوی چلېږي، او ساکټ یوازې لا هم هلته نه دی۔ له قلابه پخپله د وخت نښې لرونکې کرښه ولیکئ، اړیکه پرې او بیا ونښلوئ، او پېښې په ترتیب سره ولولئ۔ کله چې مرستندوی واقعاً تونل ته اړتیا ولري، پرېږدئ چې د تیارۍ پوښتنه وکړي د ټاکلي وخت خوب پر ځای۔

درې ساحې بل راپور ګټور جوړوي: کوم قلاب وچلېده، کوم حساب یې وکاراوه، او چېرې ودرېده۔ پرته له هغوی هر وروستی پلټنه له سره پیلېږي۔

اړوندې مقالې