איך לתעד ולאמת את כתובת היציאה של ה-VPN שבה השתמשתם
אפליקציות הלקוח מציגות שם מיקום, לא את הכתובת שממנה יצא התעבורה שלכם. תעדו את כתובת ה-IP של היציאה בזמן ההתחברות והשוו אותה לקו בסיס ישיר.
שאלו לקוח VPN לשולחן העבודה באילו שרתים השתמשתם, והתשובה הכנה היא בדרך כלל שם מיקום. השם הזה הוא נקודת הכניסה שבחרתם, והכתובת שממנה יצאה התעבורה שלכם יכולה להיות מכונה אחרת לגמרי. שום דבר באפליקציה לא נועד לשמור את המספר השני, ולכן הרשומה חייבת להיבנות ברגע השימוש. קיימות שתי גישות, ורק אחת מהן שורדת מפגש עם מקרה תמיכה.
שתי רשומות, ורק אחת מהן קיימת
התצוגה של הלקוח עצמו היא במקרה הטוב רשימה של מיקומים נבחרים עם חותמות זמן. זו החלטת עיצוב ולא מחדל: כתובות הן פרט תפעולי, הן מתחלפות בין הקצאות, וחשיפת המיפוי מקשה גם על התמיכה וגם על הטיפול בניצול לרעה. ספקים מציבים מופעי ענן לפני הרשתות שלהם בדיוק כדי שנקודת הקצה תוכל לזוז בלי לומר לאיש. מה שהאפליקציה מציגה לכם הוא הבחירה שעשיתם, לא המסלול שהתעבורה עברה.
הרשומה שאתם יכולים לבנות היא קובץ מקומי עם כתובת ציבורית אחת וחתימת זמן UTC בכל שורה. היא קטנה יותר, מכוערת יותר והרבה יותר שימושית, מפני שהיא מתארת בדיוק את מה שגם צופה מבחוץ יכול לראות.
אפשרות א׳: לתעד את כתובת היציאה בעצמכם
שירות הד מצטט את כתובת המקור שממנה הגיעה הבקשה, וזו לפי הגדרה כתובת היציאה. הריצו את התיעוד אחרי שהמנהרה מדווחת על חיבור, מפני שלקוח שאומר מחובר לפני שהמסלולים וה-DNS מתייצבים יתעד את הכתובת שלפני המנהרה וירעיל את היומן מהשורה הראשונה.
#!/bin/sh
umask 077
log="$HOME/vpn-exit.log"
printf '%s %s\n' "$(date -u +%Y-%m-%dT%H:%M:%SZ)" "$(curl -fsS https://api.ipify.org)" >> "$log"שני פרטים הופכים את הקטע הזה לשימושי ולא לקישוט. חתימת הזמן והכתובת חולקות שורה אחת, כך שניתוח מאוחר לא צריך להתאים רשומות, ו-umask 077 שומר על הקובץ פרטי מרגע יצירתו. הריצו אותו פעם אחת לכל חיבור ולא פעם אחת לכל אתחול, והחזיקו קובץ אחד לכל מכשיר.
היומן רושם מתי השתמשתם במנהרה ומאיזו רשת הופעתם, וזה קרוב יותר להיסטוריית גלישה מאשר למונה. בחרו תקופת שמירה שתוכלו להצדיק, החזיקו את הקובץ מחוץ לתיקיות סנכרון משותפות ומחקו אותו בכוונה.
אפשרות ב׳: לבקש מהספק היסטוריה
ספקים מסוימים מנהלים יומני חיבורים וישיבו לשאלת תמיכה עם חתימת זמן ושם שרת. הרשומה הזו מתארת את התשתית שלהם ולא את התעבורה שלכם, והיא שווה רק כפי ששווים חלון השמירה שלהם והנכונות שלהם להסתכל. היא גם מתארת הפעלה, לא בקשה. החלון בדרך כלל קצר, והוא נמדד מהצד של ספק המנהרה.
ספקים שמפרסמים שאינם מנהלים יומנים לא יכולים להפיק זאת לפי בקשה, ורשימת מיקומים אחרונים בצד הלקוח אינה אותו דבר. לבקש כתובת יציאה מספק בלי יומנים מסתיים בדרך כלל בהסבר למה הנתונים האלה לא קיימים.
מה כל רשומה יכולה להוכיח במקרה תמיכה
שתי הרשומות עונות על שאלות שונות, ודווקא בטבלה ההשוואה מפסיקה להיות אקדמית.
| Question | Your local log | Provider record |
|---|---|---|
| Which address did the traffic leave from? | Yes, for the moment it was captured | Usually not disclosed |
| Was the tunnel in use at 14:20? | Yes, if the capture ran | Yes, within the retention window |
| Why did a location get slower? | Yes, by comparing addresses over time | Sometimes, as an infrastructure note |
| Who sent this specific request? | No | No |
רק העמודה הראשונה בשליטתכם. רשומת ספק יכולה לאשר שחשבון היה מחובר בשעה נתונה, אבל היא לא יכולה לאשר אילו בקשות השתמשו במנהרה, והיא לא תציין כתובת שהספק מתייחס אליה כאל פרט תפעולי. אף אחת מהרשומות לא מזהה אדם, מפני שכתובת יציאה משותפת יכולה לשאת לקוחות רבים באותה דקה.
השוו את שתיהן לקו בסיס לפני שאתם סומכים על אחת מהן
כתובת לבדה לא מוכיחה דבר. תעדו את הכתובת הישירה לפני ההתחברות, ואת הכתובת שדרך המנהרה אחריה, והשוו ביניהן. ערכים זהים אומרים שהמנהרה לא נושאת את הבקשה הזו, בין אם בגלל מנהרה מפוצלת, פרוקסי עליון או לקוח שנפל חזרה למסלול ישיר.
curl -fsS https://api.ipify.org; echo
curl -fsS https://api64.ipify.org; echo
dig +short TXT o-o.myaddr.l.google.com @1.1.1.1חזרו על ההשוואה עבור DNS ועבור IPv6, מפני שהד כתובת מוכיח את המסלול של בקשת HTTP אחת ושום דבר על איזה פותר ענה. מכשיר שדולף באחד מהם יכול להיראות בריא לגמרי בשני.