د kill switch ازموینه: تشه اندازه کړئ، نه یوازې بیا وصلېدل
ژر بیا وصلېدل ښیي چې کلاینټ ژر دی. په تشه کې چې څه له ماشین څخه ووتل، هغه د خپل کارول شوي محرک سره ولیکئ، که نه ازموینې یوازې نیمه اندازه کړې.
هغه بیا وصلېدل چې په یوه ثانیه کې پای ته رسېږي تاسو ته وایي چې کلاینټ ژر دی. دا نه وایي چې د تونل د بندېدو پر مهال څه وتښتېدل. هغه بیا وصلېدل چې یوه دقیقه وخت نیسي تاسو ته وایي چې کلاینټ ورو دی، او لا هم نه وایي چې په تشه کې مستقیم ترافیک ته اجازه وه که نه. دا دوه اندازهګانې دي، او هغه kill switch ازموینه چې یوازې لومړنۍ راپور کوي، سوئچ یې نه دی ازمویلی.
دوه کتنې، دوه جلا پرېکړې
د لاسرسي پوښتنه ساده ده: تونل بیا کله د کارولو وړ شو، او ایا خوندي اپلیکیشن هلته رسېدو لپاره نوی اړیکه غوښته. د پلي کولو پوښتنه بېله ده: کوم پاکټونه له ماشین څخه ووتل، د ساتنې له لوېدو څخه تر هغې د بېرته راتلو پورې.
دوی ته په جلا ثبتونو ځواب ورکړئ. یوه کرښه وایي چې تشه ځانګړې شمېره ثانیې دوام وکړ. بله کرښه وایي چې په هغه تشه کې بې ساتنې غوښتنه بریالۍ شوه که نه. دوی په یو واحد تېر یا ناکام کې یوځای کول تر ټولو مهم حالت پټوي: د لیک سره ژر بیا وصلېدل.
داسې پروب جوړ کړئ چې وخت یې اندازه کېدای شي
داسې غوښتنه وکاروئ چې بې زیانه، ارزانه او د تونل له خپل کنټرول چینل څخه خپلواکه وي. لاندې لوپ په هر ثانیه کې یو ځل د وخت ټاپ، د HTTP حالت او تېر وخت چاپوي، او د ځړېدو پر ځای په لوړ غږ ناکامېږي:
while true; do
printf '%s ' "$(date +%H:%M:%S)"
curl -sS -o /dev/null -w '%{http_code} %{time_total}\n' --max-time 2 https://example.com || echo "curl-exit-$?"
sleep 1
done
یوازې حالت نه، د curl د وتلو کوډونه ولولئ. 28 یعنې د غوښتنې وخت ختم شو، بند لاره داسې ښکاري. 6 یعنې د نومونو تحلیل ناکام شو، چې بله موندنه ده او ډېری وخت ډېره زړه راښکونکې. په تشه کې د لږ تېر وخت سره 200 یعنې ترافیک ته د وتلو اجازه ورکړل شوه.
پایله په یوه فایل کې ولیکئ او وساتئ. د ټرمینل سکرول بیک ثبوت نه دی، او زړه راښکونکې برخه معمولاً په منځ کې درې کرښې دي.
ریښتینې ناکامي رامنځته کړئ، نه منظمه
د کلاینټ د خپل مینو څخه قطع کول همکاري لاره ازموي، چېرې چې کلاینټ د خپلو بندیز قواعدو د نصبولو وخت لري. پر ځای یې پروسه ووژنئ، یا لاندې تړاو پرې کړئ، نو هغه لاره ازموئ چې ریښتینې ناکامي پرې ځي.
هر محرک بېله کوډ لاره تمرینوي. د سرور خوا خنډ، د سیمه ییز تړاو له لاسه ورکول او د کلاینټ کریش هر یو کولای شي بېل حالت پرېږدي، او یو له دوی ښایي هغه حالت وي چې په پای کې ورسره مخامخ کېږئ. پروب لږ تر لږه په دوو محرکونو وچلوئ او پایلې د محرک له مخې لیبل کړئ.
په لاګ کې ولولئ چې اجازه ورکړل شوی ترافیک څنګه ښکاري
په تشه کې 200 یا ژر د اړیکې ناکامي یو لیک دی، هر لوري ته چې اشاره وکړي. د ټولې تشې په اوږدو کې د وخت ختمېدل د بندیز پالیسۍ تمه شوې بڼه ده. د اړیکو د ناکامېدو پر مهال د نومونو تحلیل بریالی کېدل ښیي چې حل کوونکی لا هم د لاسرسي وړ دی، چې بل ډول لیک دی.
موجود ساکټونه پاملرنې ته اړتیا لري. یو پروګرام کولای شي هغه اړیکه چې د قطع کولو دمخه یې پرانیستې وه کارول ادامه کړي، نو ژوندی ښکاره ترافیک ښایي د نوي لارې اجازه ثابته نه کړي. د ساکټونو لیست ښیي چې اړیکه له پیښې پخوانۍ ده که نه:
ss -tunp | grep -E 'ESTAB|SYN-SENT' ip route get 198.51.100.7 resolvectl status | sed -n '1,20p'
د ساکټ پیل وخت د قطع کولو د وخت ټاپ سره پرتله کړئ. له خنډ څخه پخوانۍ اړیکه د لیک نه، بلکې د ساکټ بیا کارونې ثبوت دی، او د ناکامۍ په توګه راپور ورکول یې بل کس د نه شتون لرونکي باګ په لټه کې لېږي.
پایله په داسې بڼه ثبت کړئ چې له تازه کولو وروسته هم پاتې شي
محرک، په ثانیو کې تشه، چې آیا بې بندیزه غوښتنه بریالۍ شوه، چې آیا د نومونو تحلیل بریالی شو، او د کلاینټ او عملیاتي سیسټم نسخې ولیکئ. دا پنځه حقیقتونه د خپرېدو ترمنځ پرتله کېدای شي، کوم چې یوه نثري پراګراف نشي کولای.
وروسته له کلاینټ تازه کولو یا د پروفایل بدلون څخه هماغه ازموینه بیا وچلوئ، ځکه د بندیز چلند د تطبیق تفصیل دی او هغه خوځېږي. د ثبت موخه دا ده چې خوځېدل د پیښې کېدو دمخه وپېژنئ، نه دا چې کلاینټ یو ځل تصدیق کړئ.