ה-VPN של Windows לא מתחבר? התאימו את הקוד ליומן האירועים

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

טקסט תיבת הדו-שיח הוא הצעד האחרון, לא הסיבה

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

מה שעדיין אפשר לקבוע הוא הניסיון עצמו. רשמו את שם החיבור, את סוג המנהרה השמור בפרופיל — PPTP, L2TP/IPsec, SSTP או IKEv2 — את השעה עד השנייה, ואת הקוד. אם אינכם בטוחים איזה פרוטוקול באמת רץ, פתחו את %APPDATA%\Microsoft\Network\Connections\Pbk\rasphone.pbk וקראו את הרשומה במקום לסמוך על הזיכרון; פרופיל שנעשה בו שימוש חוזר עבור פרוטוקול חדש שומר על שם התצוגה הישן שלו.

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

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

809 הוא המחלקה ההפוכה: שום דבר לא חזר. זו בעיית מסלול — TCP 443 מסונן עבור SSTP, GRE חסום עבור PPTP, UDP 500 ו-4500 או ESP נזרקים עבור מעבר IPsec. סיסמה חדשה לא יכולה לתקן את זה, וגם לא תעודה חדשה. 720 אומר שהקישור עלה ו-PPP מעולם לא סיים את המשא ומתן, מה שמצביע על אי-התאמת פרוטוקול או על שרת שלא הצליח להקצות כתובת. 789, או 13801 ב-IKEv2, הוא זהות בתוך IPsec: תעודה שהנושא שלה אינו תואם לשם שאליו אתם מחייגים, שרשרת לא מהימנה, או מפתח משותף מראש ששונה בין שני הקצוות.

משכו את אירוע RasClient של אותה דקה

במציג האירועים, Windows Logs > Application מסונן לפי מקור RasClient הוא המקום הראשון להסתכל בו. הכתיבה של Microsoft על שגיאה 720 מפנה לאירוע 20227 ביומן הזה. אותו ספק מפיק מזהים אחרים לתוצאות אחרות, אז קראו את ההודעה ואת קוד התוצאה המוטמע בה במקום להתייחס ל-ID כאבחנה; תיבת דו-שיח גנרית ועוד 20227 שנושא 720 הם כבר סיפור הרבה יותר צר.

מ-PowerShell, בלי ללחוץ דרך ה-GUI:

Get-WinEvent -FilterHashtable @{
  LogName      = 'Application'
  ProviderName = 'RasClient'
  StartTime    = (Get-Date).AddMinutes(-15)
} | Format-List TimeCreated, Id, Message

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

בנו ציר זמן אחד במקום ערימת אירועים

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

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

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

rasdial "Office VPN"
rasdial "Office VPN" /disconnect

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

מה כל שלב אומר לכם לשנות

מתן שם לשלב מועיל רק אם הוא מכווץ את סט השינויים לשכבה אחת:

• 691 — אימות: שיטת ה-EAP שהלקוח מציע מול זו שהשרת מקבל, מצב החשבון, תפוגת הסיסמה, הרשאת חיוג.
• 812 — מדיניות השרת: מדיניות הגישה מרחוק או כלל ה-NPS שמתאים למשתמש הזה ולחלון הזמן הזה.
• 809 — נגישות: כללי חומת אש במסלול, NAT ומעבר פרוטוקול, הפורט שסוג המנהרה הנבחר צריך.
• 720 — משא ומתן PPP: אי-התאמת פרוטוקול אימות, הקצאת כתובת, הגדרת PPP בצד השרת.
• 789 / 13801 — זהות IPsec: נושא התעודה מול השם שאליו אתם מחייגים, שרשרת אמון, מפתח משותף מראש.

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

שתפו את הראיות, לא את הסביבה

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

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

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