חכירה חלופית אחרי שחזור מנהרת האתר: לחדש או להמתין?

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

שני שעונים, ואחד מהם אינו המנהרה

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

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

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

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

ipconfig /all
ipconfig /release
ipconfig /renew

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

קראו את ההצעה, לא רק את הכתובת

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

tcpdump -ni any 'port 67 or port 68'

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

איפה ההשוואה מתהפכת

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

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

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

כתבו את נוהל היציאה

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

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