د OpenVPN د څو --up سکریپټونو خبرداری: یوازې یو چلیږي
د دوو up کرښو بیا ترتیبول به دواړه ونه چلوي۔ OpenVPN د هر پړاو لپاره یو فرمان ساتي، نو دواړه تعریفونه ومومئ او کار ته یو واحد د ننوتلو ټکی ورکړئ۔
د څو سکریپټونو خبرداری د مهالوېش شکایت غوندې اورېدل کېږي، نو څرګند حل دا دی چې کرښې تر هغه بیا ترتیبوو چې ورک شي۔ خو دا د مهالوېش شکایت نه دی۔ وروستی --up تعریف هغه فرمان بدلوي چې دمخه یې د دې پړاو لپاره ساتل شوی، او پارسر همدا وایي، یعنې ستاسو له دوو سکریپټونو څخه یوازې یو کله هم چل شوی دی۔ بل د هغه تر شا په قطار کې نه دی؛ هغه ورک شوی۔
نو ځکه دا خبرداری د پام وړ دی، که څه هم وژونکی نه دی: هغه څه چې وړاندوینه یې کوي یو DNS تازه کول یا د لارې بدلون دی چې په خاموشۍ کې پېښېدل بند شوي۔
خبرداری د ترتیب په اړه نه دی
OpenVPN د up پړاو لپاره یوازې یو کاري سکریپټ فرمان ساتي۔ کله چې پارسر بل تعریف ومومي، د پروفایل، شامل شوي فایل یا کمانډ کرښې څخه، هغه څه بدلوي چې دمخه یې درلودل او خبرداری ورکوي۔ هېڅ شی نه یوځای کېږي، هېڅ شی دوه ځله نه چلیږي، او د ترتیب پوښتنه نه شته۔ پاتې کېدونکی فرمان هغه دی چې پارسر ورستي ځل لیدلی، نو ځکه د یوې کرښې ښویول کېدای شي ګټونکی بدل کړي او بل سکریپټ مړ پاتې شي۔
همدا بڼه د نورو سکریپټ پړاوونو لپاره هم صدق کوي: هر یو ته یو فرمان۔ که دوو کارونو دواړو ته پېښېدل وي، دوی ته د لړلیک غوندې دوو لارښوونو نه، یو واحد د ننوتلو ټکی ته اړتیا ده۔
دواړه تعریفونه په ریښتیني پیل کې ومومئ
د هغه څه څخه پیل وکړئ چې ډیمون ریښتیني ترلاسه کړي، نه د هغه پروفایل څخه چې تاسو سمولی۔ ps -ef او د واحد ExecStart کمانډ کرښه ښیي، چې کېدای شي له کانټینر د ننوتلو ټکي یا له یوې پوښښې څخه --up ورزیات کړي؛ د وېش init فایل هم همدا کولی شي۔ systemctl cat openvpn-server@server ښیي چې خدمت پخپله څه ورزیاتوي، او په ترتیباتو فولډر کې تکراري grep د فایل کچې تعریفونه مومي۔ تکرارونه معمولاً له مختلفو طبقو راځي، او همدا لامل دی چې د یو فایل سمول هېڅ نه بدلوي۔
سکریپټ بل فولډر ته کاپي کول یا نوم بدلول هم لارښوونه نه لرې کوي۔ پارسر فایلونه نه، تعریفونه شمېري۔
یوازې یو hook د کار مالک شي
دوامداره حل یو واحد لېږدوونکی دی چې دواړه کړنې په پام شوې ترتیب سره اجرا کوي۔ د set -eu سره لنډ shell سکریپټ اړین یوځایوالی او بیا سیمه ییزه کړنه غواړي او "$@" تېروي تر څو د استدلال حدود پاتې شي؛ همدا راز چلند په یو کتنې وړ ځای کې پاتې کېږي۔ د استدلال تېرول یوازې هغه ساتي؛ دا نه ثابتوي چې دواړه مرستندویان یو شان مخ ورته تمه لري، نو د هر یوه تړون ولولئ۔ پریکړه وکړئ چې ناکامي څه باید وکړي او ایا جزوي بدلونونه باید بیرته واخیستل شي۔
که پیلوونکی د ملاتړ شوي پراختیا hook وړاندیز کوي، هغه د لاسي جوړې زنځیرې په پرتله غوره کړئ۔ د کانټینر انځور یا د پلورونکي بنډل اکثراً د اضافي کار لپاره مستند ځای لري، او د هغه کارول د دې مخه نیسي چې تازه کول ستاسو لېږدوونکی باندې ولیکي۔
پاکول د اړوند down پړاو دي۔ کوم up عمل چې DNS بیا لیکي یا لارې ورزیاتوي، مستند بېرته اخیستل غواړي، او یوازې پیل ته پام کوونکی لېږدوونکی نیم ډیزاین دی۔
یوځایوالی تایید کړئ، نه یوازې خاموشي
د تکرار خبرداری لرې کول اسانه برخه ده؛ یوځایوالی باید لا هم کار وکړي۔ له نښلېدو وروسته د resolvectl status په مرسته یا د /etc/resolv.conf لوستلو له مخې د حل کوونکي حالت وګورئ، او لارې د ip route په مرسته تایید کړئ۔ بیا نښلېدل پرېږدئ او بیا ونښلئ، ځکه چې په بیړه زنځیر شوی hook اکثراً د پخواني کړنې څخه یو څه پرېږدي۔ journalctl -u openvpn-server@server -b ښیي چې ستاسو لېږدوونکی چل شوی او څه یې چاپ کړي۔
د hook واکونه هغه ځای کې وساتئ چې باید وي۔ script-security لوړول یا ډیمون په ډېرو حقونو چلول ستاسو لپاره د بدل شوي hook حل نه دی؛ دا هغه څه پراخوي چې هر راتلونکی سکریپټ کولی شي، په شمول هغه چې یرغلګر یې نوم ورکوي۔
د دې نښه چې حل ریښتینی دی، په لاګ کې خاموشي نه ده۔ هغه د DNS ځواب، د لارې ننوتنه او پاکول دي چې د دوو بیا نښلېدنو وروسته سم کار کوي۔