לכידת ניסיון VPN בודד ב-Console של macOS

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

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

בחרו את הלקוח שנכשל בפועל

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

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

הפעילו את התצוגה החיה לפני הניסיון

פתחו את Console ובחרו את ה-Mac הזה תחת Devices, לא טלפון מחובר ולא חבילת דוח ישנה. לחצו על Start בסרגל הכלים כדי שהזרם יהיה חי, ואז רשמו את השעה עם אזור הזמן שלה. השתמשו בגישת מנהל אם התצוגה דורשת זאת, וב-Mac מנוהל בקשו את הגישה הזאת מהבעלים במקום לעקוף אותה.

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

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

צמצמו לפי תהליך ולא לפי אגדות

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

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

השאירו הקשר מספיק כדי לענות על שאלה אחת

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

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

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

שתפו את הקטע השימושי הקטן ביותר

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

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