آزمون 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'

زمان شروع سوکت را با برچسب زمان قطع مقایسه کنید. اتصالی که از قطعی قدیمی‌تر است شاهد بازاستفاده سوکت است، نه نشتی، و گزارش آن به‌عنوان خرابی نفر بعدی را به شکار اشکالی می‌فرستد که وجود ندارد.

نتیجه را در قالبی ثبت کنید که از یک به‌روزرسانی جان سالم به در ببرد

محرک، شکاف بر حسب ثانیه، اینکه آیا درخواست مسدودنشده‌ای موفق شد، اینکه آیا تحلیل نام موفق شد، و نسخه‌های کلاینت و سیستم‌عامل را بنویسید. این مجموعه پنج‌گانه از واقعیت را می‌توان میان نسخه‌ها مقایسه کرد، کاری که یک پاراگراف نثر نمی‌تواند.

همان آزمون را پس از به‌روزرسانی کلاینت یا تغییر پروفایل دوباره اجرا کنید، زیرا رفتار مسدودسازی جزئیات پیاده‌سازی است و جابه‌جا می‌شود. هدف سابقه این است که جابه‌جایی را پیش از تبدیل شدن به حادثه متوجه شوید، نه اینکه کلاینت را یک‌بار گواهی کنید.