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'

ساکٹ کے شروع ہونے کا وقت منقطع ہونے کے ٹائم اسٹیمپ سے موازنہ کریں۔ رکاوٹ سے پرانا کنکشن رساؤ کا نہیں، ساکٹ کے دوبارہ استعمال کا ثبوت ہے، اور اسے ناکامی بتانا اگلے شخص کو ایسی بگ ڈھونڈنے بھیجتا ہے جو موجود نہیں۔

نتیجہ ایسی شکل میں درج کریں جو اپ ڈیٹ کے بعد بھی رہے

محرک، سیکنڈوں میں وقفہ، کوئی غیر مسدود درخواست کامیاب ہوئی یا نہیں، نام کی تحلیل کامیاب ہوئی یا نہیں، اور کلائنٹ و آپریٹنگ سسٹم کے ورژن لکھیں۔ پانچ حقائق کا یہ مجموعہ ورژنوں کے درمیان موازنہ کے قابل ہے، جو ایک نثری پیراگراف نہیں کر سکتا۔

کلائنٹ اپ ڈیٹ یا پروفائل تبدیلی کے بعد وہی امتحان دوبارہ چلائیں، کیونکہ بلاک کرنے کا رویہ نفاذ کی تفصیل ہے اور وہ حرکت کرتا ہے۔ ریکارڈ کا مقصد واقعہ بننے سے پہلے حرکت کو نوٹ کرنا ہے، کلائنٹ کو ایک بار تصدیق کرنا نہیں۔