שגיאה 720 ב-VPN של Windows: מאגר כתובות או כריכת לקוח?
שגיאה 720 פירושה שהחיבור מעולם לא קיבל כתובת שמישה. הפרידו בין תקלות במארח אחד לתקלות במארחים רבים לפני התקנה מחדש של מתאם.
שגיאה 720 מופיעה לאחר שהאישורים מתקבלים, ולכן היא מחזירה אנשים לשדה הסיסמה. החיבור הגיע לנקודה שבה מנהלים משא ומתן על כתובת ולא קיבל אחת. שתי תקלות שונות מאוד מייצרות את אותה תיבת דו-שיח: לשרת לא היה מה לחלק, או שהלקוח הזה בדיוק לא הצליח להשלים את המשא ומתן. הפרדת השתיים לפני נגיעה במשהו היא רוב התיקון, וההפרדה מתועדת בעמוד פתרון הבעיות של Microsoft לשגיאה 720.
מה תיבת הדו-שיח משמיטה
ההודעה מתארת כשל במשא ומתן PPP, והיא מעורפלת במכוון משום שהלקוח אינו יכול לראות מדוע השרת סירב. זו אינה שגיאת אישורים, ואינה קביעה על הצפנת המנהרה. היא אומרת שהכתובת או פרמטרי המשא ומתן לא נמסרו.
בצד השרת הסיבה הרגילה היא הקצאה: מאגר סטטי של RRAS ללא כתובות פנויות, או תצורת DHCP שהטווח שלה מוצה או אינו נגיש, מייצרים בדיוק את התסמין הזה בכל לקוח שמנסה. בצד הלקוח הסיבה הרגילה היא כריכה. יש לקשור את ה-WAN Miniport שנושא את PPP לרכיבים הנכונים, וכריכה מושבתת או מסנן רשת שהוכנס יכולים לעצור את המשא ומתן בלי שום בעיית התקן גלויה. שתי המשפחות זקוקות לראיות שונות, והדרך המהירה ביותר לבחור ביניהן היא לספור כמה לקוחות נפגעו.
הפרידו את האוכלוסייה לפני המאגר
ספרו את הלקוחות שנפגעו לפני קריאת תצורה כלשהי. תקלה שפוגעת בכולם בבת אחת היא מצב שרת, ותקלה שעוקבת אחרי מכונה אחת בין רשתות היא מצב לקוח. הספירה הזאת עולה הודעה אחת בערוץ צ'אט וחוסכת אחר צהריים.
| Artifact | How you get it | What it rules out | What it cannot rule out |
|---|---|---|---|
| Affected-client count | One message to the people who failed, or a search of today's tickets | A client-only fault, when every client failed within minutes | Which server-side component stopped allocating |
| RRAS event for one attempt | Get-WinEvent on the System log, filtered to the allocation event id | An allocation failure, when no event matches that attempt | A binding fault that appears later in the same negotiation |
| Hidden WAN Miniport bindings | Get-NetAdapter with hidden adapters, then the binding list on the returned name | A disabled ms_wanarp binding or an inserted filter on this client | Pool exhaustion that would also have hit other clients |
| Free-address count | The RRAS pool view, or the DHCP scope statistics | A committed static range or an exhausted scope | Why the address was not delivered to one specific client |
לאחר מכן קשרו ניסיון כושל אחד לרשומה של השרת עצמו, משום ש-RRAS רושם אירוע כשהוא אינו יכול להקצות, והאירוע הזה נוקב בשם התקלה ולא בתסמין. אם התקלה עוקבת אחרי לקוח מסוים, יומן השרת לא יראה דבר עבור הניסיון הזה, וזה כשלעצמו מאלף. היעדר שגיאת הקצאה מצמצם את הבעיה למשא ומתן באותו לקוח ואומר אילו פקודות להריץ בהמשך.
Get-WinEvent -LogName System -MaxEvents 500 | Where-Object { $_.Id -eq 20167 }
Get-NetAdapter -IncludeHidden | Where-Object { $_.InterfaceDescription -like "WAN Miniport*" }קראו את מצב ההקצאה של השרת
בצד RRAS ודאו איזו שיטת הקצאה מוגדרת בפועל ולא איזו התיעוד מניח. מאגר סטטי ותצורה המועברת דרך DHCP נכשלים בדרכים שונות, והתיקון שייך לזו שנמצאת בשימוש. במאגר סטטי ספרו את הכתובות הפנויות וחפשו הקצאות לפי משתמש שמחזיקות חכירה שאיש אינו זוכר שיצר, משום שמאגר שנראה גדול עשוי להיות תפוס לגמרי. ב-DHCP בדקו שהממסר מגיע לשרת ושבין הטווח יש חכירות פנויות.
טווח שהוצת על ידי לקוחות רגילים מייצר את אותה 720 כמו מאגר שהוגדר לא נכון, וקונסולת RRAS תיראה בריאה לחלוטין בשני המקרים. התנגדו לעקיפה המורשת של פיצול המאגר לטווחים קטנים יותר: העצה המקורית תיארה תוצאה של מנהל אחד, והיא אינה מתקנת כשל הקצאה שאירועי השרת עצמו יכולים לנקוב בשמו ישירות.
קראו את כריכות הלקוח בלי לשבור אותן
אם הראיות מצביעות על לקוח אחד, בדקו את המתאם המוסתר במקום להתקין מחדש את הערימה. הפקודה הראשונה מפרטת את ממשקי WAN Miniport ואת שמותיהם; השנייה לוקחת את השם שהיא החזירה, ולא שם שהועתק ממדריך.
Get-NetAdapterBinding -Name "<name>" -IncludeHidden -AllBindingsקראו את הרשימה אחר כריכת פתרון הכתובות ואחר מסננים של צד שלישי. כריכה מושבתת היא תיקון ממוקד, בעוד שנוכחותו של מסנן היא שאלה לבעלים של אותה תוכנה ולא רישיון להשבית מוצר אבטחה. מחיקת כל המתאמים היא הצעד היחיד שהורס את הראיות שתזדקקו להן אם התקלה תחזור.
לאחר התיקון נסו שוב את אותו פרופיל ואז חזרו על מקרה שני הלקוחות אם זה היה התסמין המקורי, משום שחיבור ראשון מוצלח מסתיר את בעיית ההקצאה שלקוח שני חושף. שמרו את ההערה בארבעה שדות: איזה לקוח, איזו כריכה, איזה אירוע ומה השתנה. שנו גם שכבה אחת בכל ניסיון, משום שתיקון לקוח ושינוי מאגר שהוחלו יחד אינם ניתנים לייחוס, והתקלה הבאה תיראה חדשה כשהיא אותה אחת.