מבחן 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'

השוו את זמן ההתחלה של השקע לחתימת הזמן של הניתוק. חיבור ישן מהתקלה הוא ראיה לשימוש חוזר בשקע, לא לדליפה, ודיווח עליו ככשל שולח את האדם הבא לחפש באג שלא קיים.

תעדו את התוצאה בצורה ששורדת עדכון

רשמו את הטריגר, את הפער בשניות, אם בקשה לא חסומה הצליחה, אם פתרון השמות הצליח, ואת גרסאות הלקוח ומערכת ההפעלה. סט זה של חמישה עובדות ניתן להשוות בין גרסאות, מה שפסקה בפרוזה אינה יכולה.

הריצו שוב את אותו מבחן אחרי עדכון לקוח או שינוי פרופיל, כי התנהגות החסימה היא פרט מימוש והיא זזה. מטרת הרשומה היא להבחין בתזוזה לפני שהיא הופכת לתקרית, לא להסמיך את הלקוח פעם אחת.