ה-VPN מתחבר מחדש בנהיגה: החלפת רדיו או החלפת IP?
העברה בין אנטנות יכולה להשאיר את נתיב ה-IP שלם. השוו לקוחות שמעבירים את המנהרה לאלה שבונים אותה מחדש, וקראו את אירוע הרשת, לא את הנסיעה.
השיחה נופלת כשעוברים את שולי העיר, וסמל ה-VPN נעלם באותו רגע. מפתה לרשום זאת כ״החלפת האנטנה הרגה את המנהרה״. קרו שני דברים שונים, ורק אחד מהם נוגע לאנטנות. העברת רדיו יכולה להשאיר את כתובת ה-IP, את הנתיב המוגדר כברירת מחדל ואת ההפעלה שלמים לגמרי, בעוד שהחלפת כתובת אמיתית תשבור כל מנהרה שאינה יכולה לנוע איתה. ההשוואה בין האופן שבו לקוחות מטפלים במקרה השני היא התרגיל המועיל, משום שהיא אומרת לכם אם אתם רואים התנהגות מתוכננת או תקלה.
החלפת אנטנה אינה בהכרח החלפת כתובת
רשתות סלולריות משמרות את הפעלת החבילות במהלך העברות כל עוד עוגן הניידות של המפעיל נשאר זהה. הקישור הרדיופוני משתנה, המנהרה אינה מבחינה בכך, ושום התחברות מחדש לא אמורה להופיע ביומן כלשהו. זהו המקרה הרגיל של תנועה בתוך עיר.
מה שכן משנה את הכתובת הוא מעבר בין עוגנים, מעבר מ-Wi-Fi לסלולרי, או הקמה מחדש של המנהרה מצד המפעיל לאחר פער ארוך. אירועים אלה מחליפים את כתובת המקור שהחבילות שלכם נושאות, ועמית VPN רואה עמית שזז.
המסקנה המעשית היא שתנועה אינה הוכחה. מכשיר שעבר ארבעים קילומטרים אולי שמר כתובת אחת לכל הדרך, ומכשיר שעומד במקום אולי החליף כתובת פעמיים מפני שהרשת החליטה כך. רישום האירוע הוא הדרך היחידה להבחין ביניהם.
שני עיצובים: להעביר את המנהרה או לבנות אותה מחדש
לקוחות נבדלים במידה שבה אכפת להם שהמקור החיצוני השתנה. חלקם קושרים את המנהרה לכתובת שעליה נבנתה ודורשים הקמה מחדש מלאה. אחרים מאמתים כל חבילה בנפרד ורק מעדכנים לאן הם שולחים את התשובות.
| Mechanism | Behaviour after the source changes | What the user notices |
|---|---|---|
| WireGuard | Endpoint updated on the next authenticated packet | Usually nothing; the tunnel continues |
| IKEv2 with MOBIKE | Security association moves to the new address | Short pause, no re-authentication |
| OpenVPN over UDP with float | Peer address may change without a restart | Might survive, depending on timing |
| Client bound to one address | Session dies and is rebuilt | A visible reconnect and a new authentication |
השורה העליונה מסבירה דוחות מבלבלים רבים. ל-WireGuard אין הפעלה שאפשר לשבור: כל חבילה נושאת את האינדקס של העמית ומאומתת, ולכן חבילה תקפה שמגיעה מכתובת חדשה היא בהגדרה מאותו עמית, ונקודת הקצה שנרשמה עוקבת אחריה. לקוח שמציג ״מחובר״ ברציפות לאורך נסיעה אומר את האמת.
גם השורה התחתונה אינה פגם. בנייה מחדש של ההפעלה מריצה שוב את האימות מול הכתובת הנוכחית, וזה בדיוק מה שרוצים כשהכתובת הישנה עשויה כעת להיות של מישהו אחר.
התבוננו באירוע ולא בתנועה
ב-Android תת-המערכת של הקישוריות מדווחת על שינויי רשת כאירועים, ואלה הם מה שצריך לתאם עם התנהגות הלקוח. הפלט מפורט, אבל החלקים הרלוונטיים הם רשת ברירת המחדל והכתובת שלה:
adb shell dumpsys connectivity | grep -E 'NetworkAgentInfo|Default network'
adb shell ip -br addr show
adb logcat -b main -s Vpn:* | head -n 40בצד השרת יש מדידה ישירה למקרה הנדידה. WireGuard שומר את נקודת הקצה המאומתת האחרונה לכל עמית, ולכן שינוי כתובת מופיע כערך שהשתנה ולא כהתחברות מחדש:
sudo wg show wg0 endpoints
sudo wg show wg0 latest-handshakesהשוו את נקודת הקצה לפני הנסיעה ואחריה. אם הכתובת והפורט לא השתנו, המנהרה לא הייתה צריכה לעשות דבר וההתחברות מחדש באה ממקום אחר, בדרך כלל מהיישום. אם נקודת הקצה השתנתה בעוד חתימת הזמן של לחיצת היד נשארה קרוב למרווח חידוש המפתח הרגיל, המנהרה עברה ולא הופעלה מחדש.
הפעלה מחדש נראית אחרת: חתימת הזמן של לחיצת היד מתאפסת לרגע ההתחברות מחדש, והלקוח רושם רצף אתחול ולא המשך שקט.
מתי ההתחברות מחדש היא ההתנהגות הנכונה
התייחסות לכל התחברות מחדש כתקלה מובילה לתצורות שמחזיקות הפעלות מתות בחיים. עמית שהכתובת שלו השתנתה מפני שהרשת הקצתה אותה מחדש לא אמור להמשיך לקבל תעבורה עבור המיפוי הישן, ולקוח שממשיך בשקט עלול בסוף לשלוח לחור שחור בזמן שהסמל נשאר ירוק.
השוו את שתי התקלות מנקודת המבט של המשתמש. התחברות מחדש עולה כמה שניות ואימות חדש. מנהרה מיושנת עולה ביישום שנתקע בלי שגיאה, שקשה הרבה יותר להסביר וסביר הרבה יותר שידווח כ״האינטרנט התקלקל״.
מתחת לזה מסתתרת גם שאלת מדיניות. בפער שבין אובדן נתיב אחד לביסוס אחר, חלק מהלקוחות חוזרים לשלוח תעבורה ישירות. מניעת זה היא בקרה נפרדת משחזור אוטומטי, ולקוח יכול להיות טוב באחד וגרוע בשני. החליטו מה אתם צריכים לפני שתכווננו מי מהם.
רשמו את הרצף שנצפה
דוח מועיל נוקב במקור האירוע: שינוי ברשת ברירת המחדל עם כתובת חדשה, מעבר מ-Wi-Fi לסלולרי, או העברה בלי שום שינוי כתובת. אחר כך הוא מציין מה עשה הלקוח, עם חתימת הזמן מצד השרת ולא מהזיכרון.
אם המנהרה עברה, אמרו זאת וציינו את משפחת נקודות הקצה החדשה. אם היא הוקמה מחדש, ציינו אם האימות הצליח בניסיון הראשון וכמה זמן נמשך הפער. שלוש העובדות האלה מבדילות עיצוב סלולרי בריא מלקוח שמתנדנד בין רשתות.
והימנעו מהביטוי ״החלפת אנטנה״ אלא אם יומן המכשיר באמת מבסס אותו. תיעוד הקישוריות של Android מתאר את קריאות החזרה שמבדילות בין זמינות לשינוי ברשת ברירת המחדל, וההבחנה הזו היא מה שהדוח שלכם צריך. כל השאר הוא סיפור על נהיגה.