שגיאת L2TP/IPsec 789, 720 או 691: תקנו קודם את השלב הנכון

Windows 11 מדווח על מספר שונה לכל שלב של L2TP/IPsec, והמספר הזה מסמן שלב ולא מדרג את התקלה. 789 נכשל לפני שקיים קישור PPP, 720 נכשל בזמן העלאת הקישור, ו-691 נכשל לאחר שהקישור עלה ופרטי הכניסה נדחו. ההחלטה המועילה אינה איזה תיקון פופולרי יותר; אלא איזה שלב הקוד מוכיח שהגעתם אליו. קראו זאת קודם, ואז שנו שכבה אחת בכל ניסיון כדי שהקוד הבא עדיין יגיד לכם משהו.

קראו את הקוד כשלב, לא כרשימת תקלות

חיבור L2TP חוצה שלושה גבולות בסדר קבוע. IKE מנהל משא ומתן על אסוציאציות אבטחה מעל UDP 500, מעבר NAT מעביר את התעבורה הזו ל-UDP 4500, ורק אז מנהרת L2TP נושאת הפעלת PPP שמאמתת את המשתמש ומקצה כתובת.

הסדר הזה הוא הסיבה שקוד שגיאה משתנה הוא ראיה מועילה. מעבר מ-789 ל-720 אומר ש-IPsec מנהל כעת משא ומתן ושהתקלה עברה להקמת הקישור. מעבר מ-720 ל-691 אומר שהקישור עלה ושהשער דחה את הזהות. אם תחילו חמישה תיקונים בבת אחת, תאבדו את האות הזה ולא תוכלו לדעת איזה שינוי עבד.

789: בחרו בין הנתיב למדיניות המקומית

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

ודאו ש-UDP 500 ו-UDP 4500 מגיעים לשרת ושהמפתח המשותף מראש תואם בייט אחר בייט, כולל רישיות ורווחים בסוף. אם השרת נמצא מאחורי NAT, ייתכן ש-Windows זקוק גם לערך הרישום המתועד. השתמשו ב-1 כשהשרת מאחורי NAT וב-2 כששני הקצוות מאחוריו, ואז הפעילו מחדש כי סוכן המדיניות קורא את הערך באתחול:

reg add "HKLM\SYSTEM\CurrentControlSet\Services\PolicyAgent" /v AssumeUDPEncapsulationContextOnSendRule /t REG_DWORD /d 1 /f

התיקון הכבד יותר של המתאם שייך לענף האחר. הסרת התקן ה-Wi-Fi ומיני היציאות WAN ואז סריקה מחדש אחר חומרה מוצדקת כשמחסנית ה-IPsec המקומית עצמה פגומה וסוגי VPN אחרים נכשלים באותה דרך. זהו מאמץ מבוזבז כשנרק שרת L2TP אחד נכשל בעוד כל נתיב רשת אחר עובד.

720: בחרו בין המתאם הזה לבין מאגר השרתים

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

השתמשו ברדיוס ההשפעה כדי להחליט. כשל של מכונת Windows אחת מצביע על מיני יציאת WAN פגומה, שירות Remote Access עצור או פרופיל חיבור פגום. כשל של כמה לקוחות בו-זמנית מצביע על השרת: מאגר כתובות מותש, שירות RRAS עצור או מאגר שכבר אינו מתאים לתת-הרשת של הלקוח. תקנו את הצד שהתבנית מצביעה עליו לפני שתשנו את האחר.

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

691: בחרו בין פרטי הכניסה לבין עוזר עצור

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

בדקו תחילה את שדה התחום, ואז את התווים המדויקים בסיסמה. סיסמה המכילה רווח, מרכאות או תו מיוחד של מעטפת יכולה להתקלקל לפני שהיא מגיעה לשרת; ב-Linux, pppd מדווח על אותה דחייה כמו E=691 עבור ערך ללא מרכאות או תחום חסר. הקלידו את הסוד מחדש במקום להדביק אותו, ונקו כל פרט כניסה שמור שעשוי להחזיק ערך ישן יותר.

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

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

שנו שכבה אחת בכל ניסיון

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

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

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