ה־VPN לא הדליף את כתובת ה־IP הישנה שלך: ערך שנשמר עשה זאת

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

שני ההסברים מאחורי כתובת אחת

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

Address learned before the tunnel: P1
Tunnel up: the next request exits at P2
Application reuses its retained P1 in a message body
Receiver logs source P2 and submitted value P1

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

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

הזיכרון של האפליקציה שורד את ההתחברות מחדש

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

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

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

קראו קודם את כותרת המקור, ואחר כך את המטען

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

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

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

שימור הוא שלב שונה מהעברה

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

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

מה לבדוק לפני שמאשימים את המנהרה

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

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