מתג החירום מופעל: מה קורה לחיבורי TCP פתוחים?

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

זריקה, דחייה ואיפוס הם דברים שונים

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

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

מה היישום עושה בזמן שהפער נמשך

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

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

החליטו אם נדרשת התאוששות

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

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

בדקו את החסימה ואת ההתאוששות בנפרד

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

ss -tnp state established '( dport = :443 )'
sudo conntrack -L -p tcp --dport 443
sudo tcpdump -ni any 'tcp port 443 and tcp[tcpflags] & tcp-syn != 0'

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

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