מבחן מעבר: האם זרם TCP מבוסס שורד?

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

שתי תוצאות שנראות כמו הצלחה אחת

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

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

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

מה השרת רואה כשהמוצא משתנה

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

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

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

conntrack -L -d 198.51.100.20 2>/dev/null | head
ss -tin dst 198.51.100.20
tcpdump -ni any host 198.51.100.20 -c 10

מדוע אותה כתובת ציבורית אינה מספיקה

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

RFC 3022 מתאר תרגום כתובות ומתייחס להחלפת מצב בין התקנים מתרגמים כחלק מתכנון גיבוי. כתובת צפה או פרופיל מועתק מעבירים את התצורה בלי להעביר את המצב.

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

החליטו כמה חזקה הדרישה

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

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

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

בדקו את הזרם הישן ואת הבקשה החדשה

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

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

ss -tin dst 198.51.100.20
curl -sS -o /dev/null -w '%{http_code} %{time_total}\n' https://198.51.100.20/
tcpdump -ni any port 443 -c 20

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