שגיאה 868 עם כתובת IP? מה Windows מפענח קודם
תיבת הדו־שיח מדווחת על כשל חיפוש בעוד הפרופיל נראה מספרי. קראו את השדה האמיתי של הפרופיל, ואז הפרידו בעיית שם מבאג התחברות מחדש ישן.
תיבת הדו־שיח מודיעה שלא ניתן היה לפענח את שם השרת, והשדה בפרופיל שאתם בוהים בו הוא כתובת. הצירוף הזה אינו סתירה: הלקוח מפענח משהו אחר מהערך שאתם חושבים שהוא קורא. בררו למה הוא באמת מחייג לפני שאתם מסיקים ש־DNS שבור. סדר השלבים של הלקוח עצמו מראה לכם היכן לחפש.
הלקוח מפענח שם לפני שהוא מחייג
חיבור VPN מקורי של Windows קורא את הפרופיל שלו, מפענח את כתובת השרת, מפעיל את המנהרה ורק אחר כך מאמת. שגיאה 868 שייכת לשלב השני. מכיוון שהשלבים המאוחרים לא רצים כלל, תיבת הדו־שיח יכולה להיראות כמו בעיית אישורים כשהחיפוש נכשל ראשון.
הסדר הזה שימושי, מפני שהוא מצמצם את השכבה לבדיקה. כאשר אותו פרופיל עובד מרשת אחת ונכשל מרשת אחרת, ההבדל הוא בדרך כלל פענוח שמות ולא סוג המנהרה או החשבון. בדקו את החיפוש במקום שבו הכשל מתרחש, לא במקום שבו נבנה הפרופיל.
איזה שם, כשהשדה מציג כתובת
קראו את הערך השמור ולא את השם המוצג. התווית של חיבור אינה כתובת השרת שלו, ושתי רשומות עם תוויות דומות שולחות אתכם אחרי הלא נכונה:
Get-VpnConnection -Name "Work VPN" |
Select-Object Name, ServerAddress, TunnelTypeאם הפרופיל הוקצה לכל המשתמשים, שאלו גם את ההיקף הזה באמצעות -AllUserConnection. אחר כך פענחו בדיוק את הערך שהפקודה הדפיסה, מהרשת שבה הכשל מתרחש. השתמשו בשער המתועד של המפעיל, ולא בשם היישום הפנימי שמתפענח רק אחרי שהמנהרה עולה. אותה שאילתה שנייה נכשלת מסיבה צפויה ואינה אומרת לכם דבר על החיוג:
Resolve-DnsName vpn.example.comכשהערך השמור הוא באמת מספרי, חפשו מקום שני שבו הלקוח קורא שם. תצורת EAP יכולה להפנות לשרת, פרופיל שיובא מכלי אחר יכול לשאת ערך משלו, ומתקין קודם יכול להשאיר רשומה כפולה. השדה בתיבה אינו תמיד הקלט היחיד.
דפוס ההתחברות מחדש של Windows 7
השרשור שמאחורי השגיאה הזו מתאר מכונות שהתחברו פעם אחת ואז נכשלו בניסיון מאוחר יותר עם 868, בלי ששום דבר השתנה בפרופיל. תורמים דיווחו שהפעלה מחדש של שירות Remote Access Connection Manager או התנתקות והתחברות מחדש החזירו את החיבור זמנית. אלו מעקפים, לא סיבת שורש מוכחת.
התייחסו לדפוס הזה כהשערה נפרדת. הפעלה מחדש מאפסת את מצב הלקוח, ולכן הצלחה זמנית לאחר מכן אינה מוכיחה שרשומת ה־DNS הייתה שגויה:
| Observation | Points toward | What to do next |
|---|---|---|
| Fails from one network, works from another | Name resolution on that path | Resolve the stored name from both networks |
| Fails after a disconnect, works after service restart | Client state, not DNS | Record the sequence for the vendor |
| Fails only on a newly provisioned machine | Profile content or scope | Compare ServerAddress and TunnelType |
קראו את הטבלה כמערכת תצפיות מבדילות ולא כאבחנה. השורה הראשונה היא בעיית שם, השנייה מצב הלקוח והשלישית פרופיל שמעולם לא היה נכון. כל אחת מובילה לאדם אחר ולתיקון אחר.
מה לאסוף עבור המנהל
רשמו את שם הפרופיל, הכתובת השמורה, סוג המנהרה, הרשת שבה היה הלקוח, והאם הכשל בא לאחר ניתוק. הרשומה הזו מפרידה כשל חיפוש אמיתי מהתנהגות ההתחברות מחדש ההיסטורית בלי שמישהו יצטרך לנחש. שמרו גם את יומן האירועים של הלקוח סביב הניסיון.
המעקף מגרסאות ישנות הוא ראיה שההתנהגות הייתה קיימת, לא הבטחה שאותה הפעלה מחדש של השירות תתקן מכונה נוכחית. החלפת שם מארח מתועד בכתובת מפורשת אינה תיקון גם כן.
יש פרופילים שמצפים לזהות שרת שתואמת את השם המוגדר, ולכן מעקף מספרי יכול להחליף שגיאה אחת באחרת. אם השם חייב להישאר, תקנו את נתיב הפענוח ולא את טקסט הפרופיל. בכל מקרה, רשמו מה שיניתם ולמה.