ה-VPN נופל אחרי חידוש DHCP? השוו את הכתובות

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

התחילו בלקוח שנפל

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

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

השוו את ארבעת הערכים סביב האירוע

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

ip -4 -brief addr show dev wlan0
ip -4 route show default
resolvectl status | grep -A3 'DNS Servers'
journalctl -u NetworkManager --since -10m --no-pager | grep -i dhcp

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

מה חידוש יכול לשנות ומה לא

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

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

כשהלקוח לא מצליח להסתגל

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

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

חזרו על האירוע לפני שאתם מאשימים אותו

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

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