OpenVPN له TLS تیروتنې وروسته بیا بیا هڅه کوي: څنګه یې ودروو

کلاینټ نښلوي، د TLS خبرو اترو پر مهال ناکام کیږي، انتظار کوي او هماغه سرور بیا هڅه کوي په هماغه پایله۔ د یوه څارونکي تر لاندې چې ناکامه پروسه بیا پیلوي، هغه هڅې په ژورنال کې بې پایه څرخ ته اړیږي، او لومړنۍ تشخیصي کرښه له لاسرسي وتلې۔ OpenVPN داسې انتخاب وړاندې کوي چې هغه خبرو اترو ناکامي په بله هڅه نه، بلکې په لیدل کیدونکې وتنه بدلوي۔ دا د تشخیص او څارنې ترتیب دی، نه ترمیم، نو له هغه پالیسۍ سره یې یوځای کړئ چې پروسې ته په رښتیا د بند پاتې کیدو اجازه ورکوي۔

هغه څرخ چې لومړنۍ تیروتنه پټوي

هغه څه چې ګورئ یوه ناکامي نه، بلکې تکراریدونکی بلاک دی: د نښلولو هڅه، TLS تیروتنه، یوه وقفه او بیا هماغه ترتیب۔ هره تکرارونه اصلي کرښه په ژورنال کې نوره لوړه ټېله کوي۔ که واحد په ناکامي کې بیا پیل شي، څرخ کیدای شي ساعتونه دوام وکړي او هیچا لامل نه لولي۔ نښه څرخ دی، که څه هم بنسټیز عیب یوه خبرو اترو ستونزه ده۔

تعاملي ناستې دا زغمي ځکه چې لنډمهاله ناکامي ممکن په بله هڅه کې له منځه ولاړه شي۔ اتومات نښلونکي نشي کولی هماغه خوشباوري وزغمي: پروسه باید ودریږي تر څو انسان یا مانیټر حالت وویني۔

له هر بدلون مخکې یو بشپړ څرخ ثبت کړئ۔ لرې پته، په تیروتنه کې نومول شوی TLS پړاو او دا چې پروسه په بشپړ ډول وځي که نه، ولیکئ۔

د څرخ شاته د بیا هڅې ماشین

بیا هڅه ډیفالټ ده ځکه چې څو نااړوند وخت محدودیتونه هماغه ماشین شریکوي۔ connect-retry د نښلولو هڅو ترمنځ وقفه ټاکي، connect-retry-max کیدای شي محدود کړي چې هر لرې ننوتنه څو ځله ازمایل کیږي، او resolv-retry تکراري نوم پلټنې کنټرولوي۔ د TLS خبرو اترو ناکامي لکه د ترانسپورت پېښې په توګه هغه ماشین ته رسیږي، نو کلاینټ د راپور ورکولو پر ځای بله هڅه پلانوي۔ ډیفالټ ارزښت د بې ثباته لینک لپاره ګټور او د هغه عیب لپاره زیانمن دی چې نشي روغیدلی۔

--tls-exit انتخاب یوازې د خبرو اترو حالت بدلوي۔ لارښود هغه د TLS خبرو اترو ناکامي پر مهال وتنه بولي، کومه چې په هرې تیروتنې وتنې ته له محدودې تنګه ده۔ وخت محدودیتونه، د حل کوونکي ناکامۍ او د تصدیق ردونه خپل چلند ساتي۔

کلاینټ دې د TLS ناکامي پر مهال ووځي

tls-exit په هغه پروفایل کې کیږدئ چې کلاینټ یې په رښتیا لوډ کوي، یا د پیل پر مهال --tls-exit ورکړئ، او یو ځل یې په مخکیني پلان کې وچلوئ۔ د وتلو حالت او د لوګ وروستۍ کرښه ولولئ، ځکه څارونکی پر حالت عمل کوي۔ د خبرو اترو له ناکامۍ وروسته غیر صفر وتنه هغه مطلوب پایله ده۔ که پروسه د پای ته رسولو پر ځای بیا هڅه ته دوام ورکړي، انتخاب په هغه پروفایل کې ندی چې کلاینټ یې په رښتیا لوډ کوي۔

څارونکی پرېکړه کوي چې هغه وتنه لیدل کیدونکې ده که نه۔ د systemd واحد چې Restart=always یا Restart=on-failure لري کلاینټ بیا پیلوي، نو څرخ دوام کوي او انتخاب داسې ښکاري چې هېڅ نه کوي۔ له کلاینټ د شکایت مخکې پالیسي وګورئ:

systemctl show -p Restart -p RestartSec openvpn-client@office
journalctl -u openvpn-client@office -n 40 --no-pager

Restart=no پروسې ته اجازه ورکوي چې بند پاتې شي، او Restart=on-failure د غیر صفر حالت وروسته هم بیا پیلوي۔ که غواړئ ناکامي ښکاره وي خو خدمت له نااړوندو پېښو راټول شي، Restart=on-failure وټاکئ او د بیا پیل طوفان بندولو لپاره StartLimitBurst او StartLimitIntervalSec وکاروئ۔ بیا د وروستي وتلو کوډ د تایید لپاره د واحد حالت ولولئ: systemctl status هغه راپور کوي، او ژورنال لومړنۍ تیروتنه د بیا پیلونو پورته ساتي۔

پرېکړه په واحد یا په پروفایل یادښتونو کې ولیکئ۔ هغه پروفایل چې د TLS ناکامي پر مهال وځي، د بل کس لپاره پېښه ښکاري پرته له دې چې لامل ولیکل شي۔ معلومه کړئ کومې ناکامۍ پروسه ودروي او کومې بیا هڅول شي۔

د یو ځل کارولو پای نقطې سره یې ثابت کړئ

تر څو د هغې له باور مخکې چلند ووینئ، پروفایل کاپي کړئ او کاپي داسې پای نقطې ته واړوئ چې TCP نښلونکی مني خو هېڅکله OpenVPN نه بولي۔ هغه اوریدونکی چې ځواب ورکړي او بیا چوپ پاتې شي کافي دی۔ د tls-exit سره، کله چې لاس ورکول ناکام شي کلاینټ باید پای ته ورسیږي؛ پرته له هغې هماغه پروفایل باید څرخ ته دوام ورکړي۔ کاپي وکاروئ، هېڅکله کاري پروفایل نه۔

دوه چلندونه د وتلو حالت او لومړنۍ تیروتنې کرښې سره پرتله کړئ، نه د دې سره چې هر یو څومره وخت ونیول۔ حالت وایي انتخاب وشو که نه، او لومړنۍ کرښه وایي کوم پړاو ناکام شو۔

کله چې پای ته ورسیدئ ازموینه پروفایل لرې کړئ۔ د ناغوښتې غلطې پای نقطې سره کاپي د هر هغه چا لپاره چې وروسته په فولډر کې هره پروفایل پیلوي، یوه تله ده۔

هغه پړاوونه چې دا انتخاب هېڅکله نه رسیږي

د تصدیق رد یو وروستی پړاو دی۔ که سرور حساب ارزوي او رد یې کړي، TLS لا دمخه شوی، نو tls-exit نه پیل کیږي۔ د تصدیق بیا هڅې تنظیمات بل کتلو ځای دی، او د سرور لامل د کلاینټ له وروستۍ کرښې مهم دی۔ غلط پټنوم او ورک شوی سند کیدای شي کلاینټ پلوه ورته پیغامونه جوړ کړي۔

ورک شوی لار، غلط حل کوونکی یا نه رسیږونکی ګېټ وې هم دې انتخاب څخه بهر دي، ځکه دوی د خبرو اترو ناکامۍ نه دي۔ غلی پیکټ ضایع د تر ټولو کم روښانه حالت دی: د تبادلې د هغې اندازې له مخې چې څومره مخته تللې، کلاینټ کیدای شي د خبرو اترو ناکامي راپور کړي یا یوازې وخت تیر شي۔

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