د OpenVPN client-connect ناکامي: آیا د disconnect پر مهال پاکوالی تضمین ده؟
رد شوی کلاینټ د فایر وال قاعده یا لیکل شوی ریکارډ نه بیرته اخلي. د callback تړون د هغه بیرته اخیستنې سره پرتله کړئ چې ستاسو hook باید پخپله ترسره کړي.
کله چې client-connect سکریپټ د غیر صفر کوډ سره ووځي، OpenVPN کلاینټ ردوي، او چلونکي معمولاً فکر کوي چې اړوند client-disconnect سکریپټ به هر څه سم کړي. ډیری وختونه هغه هیڅکله نه چلیږي، ځکه چې د disconnect پروسس د دې پورې تړلی دی چې connect پړاو څه بشپړ کړای شول. رد او بیرته اخیستنه د یوې طریقې په توګه ګڼل هغه څه دي چې ناکامه ننوتنه په توییدلې فایر وال قاعدې یا یتیم ریکارډ بدلوي. دا دوه جلا مسؤلیتونه دي، او یوازې یو یې اتوماتیک دی. مخکې لدې چې سرور په پاتې حالت تورن کړئ، د hook خپله وتلو لاره ولولئ.
غیر صفر وتل کلاینټ ردوي؛ خو ستاسو کار نه بیرته اخلي
د client-connect د وتلو حالت د منلو پرېکړه ده. صفر یعنې منل، هر بل څه یعنې دا چې انسټنس مخکې لدې چې په بشپړه توګه جوړ شي، ړنګ کړئ. په دې تړون کې هیڅ شی نه ګوري چې سکریپټ له بهرنۍ نړۍ سره څه کړي دي. که سکریپټ د iptables قاعده ورزیاته کړې، کرښه لیکلې یا کاونټر لوړ کړی وي، هغه بدلونونه له رد وروسته هم پاتې کیږي.
همدا نابرابري د پلگ انونو لپاره هم صدق کوي، چېرې چې د یو انسټنس لپاره څو connect افعال چلیږي. وروستی ناکامي پخوانۍ بریا په شا لوري نه لغوه کوي، او پخوانی فعل هیڅ لاره نه لري چې پوه شي خور فعل ناکام شوی.
رد اتوماتیک دی، پاکوالی نه
د OpenVPN 2.6 لارښود د client-disconnect پروسس د پخواني connect پروسس د بریا سره تړي. یو مستند استثنا کاسکیډ لړۍ رانغاړي: که یو connect ګام مخکې بریا بیرته راوړې وي، د انسټنس د ړنګولو پر مهال اړوند disconnect ګامونه بیا هم چلیږي، حتی که وروستی connect ګام ناکام شوی وي. هغه استثنا تنګ دی او د دې پورې تړلی چې څو callbackونه تنظیم شوي، نو ځکه د یو shell سکریپټ ازموینه تاسو ته د لړۍ په اړه هیڅ نه وایي.
مخکې لدې چې د دې شاوخوا ډیزاین وکړئ، ریښتینی ترتیب نقشه کړئ: کوم سکریپټ، کوم پلگ ان او په کوم ترتیب چلیږي. لاندې جدول لیست کوي چې نیمګړی ترتیب څه پاتې کوي.
| What the hook did before failing | What the client sees | What stays behind |
|---|---|---|
| Created a firewall entry | A rejection, with no tunnel | A rule matching an address nobody owns |
| Wrote a state row | A rejection, with no tunnel | A record of a session that never started |
| Allocated a tunnel address | A rejection, with no tunnel | An address marked busy until something releases it |
هره کرښه د کلاینټ لپاره یو شان او د کوربه لپاره بل شان ته رسیږي. کلاینټ نشي ویلای چې کوم یې شوی، نو hook باید مخکې لدې چې د ناکامۍ حالت بیرته راوړي، خپل کړی کار بیرته واخلي.
په هغه سکریپټ کې چې ناکام شو، جبران وکړئ
مخکې لدې چې شریک حالت ته لاس وروړئ، هر هغه څه تایید کړئ چې شونې ده: د سند ساحې، د پت شتون، هغه ډله چې کلاینټ پکې دی. ترټولو ارزانه رد هغه دی چې د هر ډول تخصیص مخکې پیښیږي. کله چې ترتیب څو بهرني عملیات رانغاړي، ثبت کړئ کوم یې بشپړ شول او مخکې لدې چې د ناکامۍ حالت بیرته راوړئ، هغه په معکوس ترتیب بیرته واخلئ.
یو مشخص مثال: سکریپټ د هر کلاینټ لپاره د فایر وال ننوتنه جوړوي، بیا د هغې د بیانولو حالت کرښه لیکل ناکامیږي. ناکامه څانګه باید همدا اوس جوړه شوې ننوتنه لرې کړي او بیا د غیر صفر کوډ سره ووځي. د هغه disconnect پیښې انتظار چې کیدای شي هیڅکله مهال شوې نه وي، همدا هغه لاره ده چې قاعده خپل هدف سیشن څخه اوږده ژوند کوي.
جبران د ایمپوټینټ او مالکیت لرونکی کړئ
پاکوالی باید دوه ځله چلولو لپاره خوندي او د دې په اړه دقیق وي چې څه ړنګولای شي. د پخواني هڅې ناوخته پیښه نه باید د نوي سیشن تخصیص لرې کړي یوازې ځکه چې دواړه یو ګډ نوم یا بیا کارول شوی تونل پت لري. ځانګړی هینډل یا د عملیاتو ID د سرچینې سره ثبت کړئ، او د نوم له مخې نه، بلکې د همغه کیلي له مخې ړنګ کړئ. د ډیټابیس معاملې یوازې د ډیټابیس خپلو بدلونونو کې مرسته کوي؛ د دې حد څخه بهر فایر وال قاعده ښکاره جبراني ګام ته اړتیا لري.
فرض کړئ چې پروسه د بدلون او پاکوالي ترمنځ مړه کیدای شي، او یو همغږی کوونکی اضافه کړئ چې د مهال ویش له مخې بهرنی حالت د منل شوو کلاینټونو لیست سره پرتله کوي.
هغه درې لارې ازموئ چې واقعاً توپیر لري
درې حالتونه تمرین کړئ: مخکې لدې چې څه تخصیص شي رد، جزوي تخصیص وروسته رد، او یو نورمال منل شوی سیشن چې وروسته پای ته رسیږي. هغه درې مختلف لاګ کرښې او مختلف پاتې شوني تولیدوي. له هر یوه وروسته بهرنی حالت وګورئ، نه یوازې د کلاینټ د ناکامۍ پیغام، ځکه چې په درېیو کې دوه کې د کلاینټ ناکامي تمه شوې پایله ده.
د hook پړاو، د وتلو حالت او څه چې تخصیص یا خوشې شول، پرته لدې اعتبارنامې لاګ کړئ. هغه hook لاګ چې د خپل جوړ شوي سرچینې نوم اخلي، همغه توییدلې قاعده شپږ میاشتې وروسته د موندلو وړ ګرځوي.