מה יומני מערכת מקומיים מגלים על חיבור VPN
מערכת ההפעלה מתעדת התחלות שירות, שינויי מתאם וכשלי נתיב שאפליקציה לא כותבת לעולם. קראו חלון צר אחד ותאמו ביניהם.
כל שולחן עבודה מנהל תיעוד משלו של מה ש-VPN עשה, והייצוא של האפליקציה הוא בדרך כלל הפחות שלם מביניהם. מנהלי שירותים מציינים מתי יחידה הופעלה, הגרעין מציין מתי הופיע ממשק, ומחסנית הרשת מציינת מתי נתיבים לא הצליחו להיות מיושמים. אף אחד מהמנגנונים האלה לא יודע מה הלקוח התכוון, והלקוח לא יודע מה הגרעין עשה עם הבקשה שלו.
קריאה של תיעוד כזה בבידוד מזמינה את המסקנה השגויה. קראו שניים, מאותה דקה, והרצף נעשה גלוי.
שלושה מנגנונים ושלוש מערכות מונחים
ב-Linux יומן systemd לוכד הודעות מחזור חיים של יחידה מ-wg-quick@wg0 או מתוסף ה-VPN של NetworkManager, וחוצץ הטבעת של הגרעין נושא הודעות ממשק וניתוב. ב-Windows יומן האירועים מחלק את הסיפור בין ספקי מערכת, WLAN וגישה מרחוק, ולכל אחד מזהים משלו. ב-macOS היומן המאוחד נושא הודעות שמוגבלות לתת-מערכת, שאותן ה-Console הגרפי חושף רק בחלקן.
אין תרגום בין מערכות המונחים. מזהה אירוע מפלטפורמה אחת אינו אומר דבר באחרת, וצילום מסך של דו-שיח Windows אינו מוכיח דבר על יחידה ב-Linux.
מה שמשותף לשלושתם הוא חתימת זמן, מקור וחומרה, והשלישייה הזאת היא שמאפשרת התאמה בין יומן לקוח לרשומת מערכת הפעלה. גם הזמינות משתנה: מכולה בלי יומן, תמונת Windows מצומצמת או רמת רישום שהונמכה בזמן הבנייה יכולים להסתיר שכבה שלמה.
| Facility | What it records | What it cannot show |
|---|---|---|
| systemd journal | Unit start and stop, helper output, exit status | Whether packets actually reached the peer |
| Kernel and netlink | Interface creation, address assignment, route changes | Why the client asked for that configuration |
| Windows event log | Provider-specific connection and adapter events | Anything the provider chose not to log |
מה מוכיח שורה מחוברת ומה לא
אירוע התחלת שירות מתעד שהתבקשה מהיחידה המקומית להתחיל ושהיא לא יצאה מיד. הוא אינו מתעד לחיצת יד שהושלמה, מפתח עמית תקף או נתיב שעובד. להתייחס לשורה הזאת כהוכחה למנהרה הוא הקריאה השגויה הנפוצה ביותר של היומנים האלה. השורה מוכיחה כוונה ומצב תהליך, וכלל לא דבר על נגישות.
מצב ההעברה הוא תצפית נפרדת, והוא מגיע מטבלת הניתוב ולא מאף יומן.
אירוע מתאם יכול להסביר כשל שקט: הממשק עלה, הכתובת הוקצתה, והנתיבים מעולם לא הותקנו משום שכלל מדיניות דחה אותם. ברצף כזה כל שורה נראית בריאה בעוד שדבר אינו מנותב, והדרך היחידה לראות זאת היא להשוות את חתימות הזמן של היומן לטבלת הניתוב באותו רגע. החזיקו את סדר האירועים של הלקוח לצד שניהם, כי הלקוח הוא המקור היחיד שיודע מה ביקש. שתי העובדות שנחוצות יחד כמעט אינן מופיעות באותה שורה.
התחברות מאוחרת יותר דורסת את החלק המעניין בתמונה הזאת, ולכן תפסו את החלון בכשל הראשון ולא אחרי שלושה ניסיונות.
התאימו חלון צר
רשמו את זמן הניסיון עם אזור הזמן שלו, ואז משכו את הדקות הספורות שסביבו. השגיאה הראשונה בחלון כמעט תמיד קודמת לשורת הניתוק שקריאות התמיכה מצטטות.
journalctl -u wg-quick@wg0 --since "today 09:00" --until "today 09:20" ip route show table all | grep wg0 log show --last 20m --predicate 'subsystem == "com.apple.network"'
כל פקודה עונה על חלק אחר של השאלה: הראשונה נותנת את מחזור החיים, השנייה את מצב ההעברה, השלישית את תת-מערכת הרשת של macOS. ב-Windows סננו את יומן המערכת לפי שם הספק במקום לגלול את כל הערוץ, וייצאו רק את האירועים המתאימים.
החזיקו את הקטע קטן מספיק שקורא יוכל לעקוב אחריו. חלון של עשרים דקות עם ארבעה אירועים רלוונטיים תומך במסקנה; ייצוא של יום שלם עם אלפי שורות אינו תומך בדבר.
היכן הרשומות האלה נעצרות
רשומות מקומיות מתארות את המכשיר, לא את הנתיב. הן אינן יכולות להראות מה ספק שמר, אם הפעלה הותאמה לחשבון, או מה ראתה יעד. הצהרה של ספק שאינו שומר יומנים אינה אומרת דבר על מערכת ההפעלה במחשב הנייד שלכם, ואירוע מקומי אינו מוכיח דבר על הרשומות ההיסטוריות של הספק.
הן גם נושאות יותר נתונים אישיים מהצפוי: שמות משתמשים, שמות מארחים, נתיבי עיגון ומזהי התקן מופיעים בהודעות מערכת רגילות גם כשאין תוכן גלישה. הסירו אותם לפני שמצרפים משהו לקריאה, ושמרו את המקור תחת בקרות גישה רגילות.
במכשיר מנוהל, בקשו את הקטע הרלוונטי מה-IT במקום לנסות למחוק תיעוד ארגוני. המטרה האבחונית היא שאלה צרה אחת ששני מקורות עונים עליה, ולא היסטוריה מלאה של המכונה.