שגיאה 789 ב-L2TP/IPsec ב-Windows: צרו את הפרופיל וקבעו את ההצעה
שגיאה 789 נכשלת בחילופי ה-IPsec, לא בסיסמה. כתבו את פרופיל ה-L2TP כסקריפט, קבעו את ההצעה וקראו קודים מאוחרים לפי שלב.
שגיאה 789 בחיבור L2TP ב-Windows פירושה שהמנהרה מתה בתוך חילופי האבטחה של IPsec, וזה קורה הרבה לפני ש-Windows שולח סיסמת משתמש לאנשהו. ניסיון חוזר עם הסיסמה, או איפוס שלה בספרייה, לא יכולים לקדם את השלב הזה. מה שכן מקדם אותו הוא בנייה מחדש של החיבור מ-PowerShell עם ההצעה שהשער מציע באמת, כי אשף ההגדרות בוחר את טרנספורמציות ה-IPsec בשקט ואף פעם לא מראה לכם מה הוא בחר. זהו ספר ההפעלה לכך: צרו את הפרופיל, קבעו את ההצעה, ואז השתמשו בטבלת שלבים כדי שהקוד הבא יגיד לכם משהו.
צרו את הפרופיל בלי האשף
Add-VpnConnection כותב רשומת ספר טלפונים מקורית, כך שהתוצאה היא אותו אובייקט שאפליקציית ההגדרות תערוך מאוחר יותר. הפעילו אותו מהפעלה מורמת כשהחיבור צריך להתקיים לכל חשבון במחשב, או מהקשר המשתמש כשהוא צריך להישאר פרטי:
Add-VpnConnection -Name "Contoso L2TP" `
-ServerAddress 203.0.113.10 `
-TunnelType L2tp `
-EncryptionLevel Required `
-AuthenticationMethod MSChapv2 `
-RememberCredential -Forceהתאימו את -AuthenticationMethod למה שהשער מציע. MSChapv2, EAP ו-PAP אינם ניתנים להחלפה, ופרופיל שדורש שיטה שהשרת לא יקבל נכשל לפני שנבדק רשומת משתמש כלשהי. שמרו על -EncryptionLevel Required לכל דבר אמיתי; Optional מאפשר ל-Windows לקבל מנהרה לא מוצפנת אם הצד השני מציע כזו, וזה קיצור דרך מעבדתי ולא הגדרה לשלוח.
אם תעבירו -L2tpPsk, המפתח המשותף מראש הזה נכתב לפרופיל בדיסק, משם כל מי שיכול לקרוא את הפרופיל במחשב הזה יכול לשחזר אותו. השתמשו בתעודה לאימות הצד השני כשהשער תומך בכך, וכשהמפתח PSK בלתי נמנע, החזיקו אותו מחוץ למאגר ומחוץ להיסטוריית המעטפת במקום להדביק אותו בכל ריצת אספקה.
קבעו את ההצעה במקום לקבל את ברירות המחדל
Windows ממלא את טרנספורמציות ה-IPsec בעצמו, ולכן שני מחשבים עם חיבור שנראה זהה יכולים להיכשל אחרת מול אותו שער. Set-VpnConnectionIPsecConfiguration היא הדרך הנתמכת לקבע אותן:
Set-VpnConnectionIPsecConfiguration -ConnectionName "Contoso L2TP" `
-AuthenticationTransformConstants SHA256128 `
-CipherTransformConstants AES128 `
-EncryptionMethod AES128 `
-IntegrityCheckMethod SHA256 `
-DHGroup Group14 `
-PfsGroup None `
-PassThru -Forceהקבוצה הזו היא סידור L2TP/IPsec נפוץ אחד, לא תשובה אוניברסלית. כל פרמטר מקבל רשימה קבועה של ערכים, וצירוף שהפלטפורמה לא יכולה למפות חוזר כשגיאת cmdlet במקום פרופיל שנחלש בשקט. התייחסו לשגיאה כזו כאמירה על הערכים, לא על ההרשאות שלכם.
העתיקו את ההצעה מתיעוד השער או מהגדרות השלב 1 והשלב 2 החיות שלו, ושנו שדה אחד בכל פעם רק בזמן שהשער מתעד את הטרנספורמציות שהוא דוחה. מעבר על חמישה שדות מייצר חיבור שעובד בטעות ורשומה שלא מסבירה דבר לאדם הבא.
קראו כשל לפי שלב, לא לפי טקסט השגיאה
789 שייכת ל-משפחה של קודים שכולם נראים אותו דבר בדיאלוג הלקוח. הציבו את הקוד מול השלב שאליו הוא שייך לפני שתיגעו שוב בפרופיל:
| What you see | Stage that failed | Check first |
|---|---|---|
| Nothing happens, then a timeout | No IKE response at all | Server address, UDP 500 and 4500 reachability, NAT traversal on the gateway |
| Error 789 | IKE security exchange | Proposal, pre-shared key, certificate trust and client clock |
| Error 691 or a repeated password prompt | User authentication | Account state, domain, RADIUS or NPS policy |
| Tunnel up, some hosts unreachable | Routing or DNS after PPP | Split-tunnel routes, pushed DNS, remote subnet mask |
שני תפקידי ההסמכה חשובים כאן. מפתח משותף מראש או תעודה מאמתים את הצדדים זה לזה, ואילו MSChapv2 או EAP מאמתים אתכם בתוך המנהרה. איפוס סיסמת משתמש לא יכול לתקן את הראשון, סוד משותף חדש לא יכול לתקן את השני, ושינוי שניהם בבת אחת הורס את הראיה איזה מהם היה שגוי.
במסלול התעודה, בדקו את שעון הלקוח, שרשרת האמון והזהות שהשער מצפה לה לפני שתשקלו להקל את האימות. השבתת האימות הופכת 789 גלויה למנהרה שמתחברת בזמן שהיא נותנת אמון בצד הלא נכון, ושום דבר בלקוח לא יגיד לכם שזה קרה. רשימת שגיאות הגישה מרחוק של Microsoft היא ההפניה לקודים עצמם, והיא מפרידה בין כשלי שכבת האבטחה לכשלי הכניסה.
אמתו משני הקצוות לפני שאתם מכריזים שזה תוקן
קראו את הפרופיל בחזרה, אבל אל תצפו לראות את ההצעה בפלט. Get-VpnConnection מדווח על השם, כתובת השרת, סוג המנהרה, רמת ההצפנה ושיטת האימות, והוא לא יודע דבר על טרנספורמציות, כך שהקריאה מאשרת שהרשומה קיימת ומצביעה על המארח הנכון:
Get-VpnConnection -Name "Contoso L2TP" |
Select-Object Name, ServerAddress, TunnelType, EncryptionLevel, AuthenticationMethodחייגו משורת הפקודה כדי לקבל מספר במקום דיאלוג: rasdial "Contoso L2TP" מחזיר את אותו קוד כשל שהממשק היה מחזיר, ו-rasdial "Contoso L2TP" /disconnect מנקה אותו בין ניסיונות. לאחר מכן קראו את צד השער לאותו ניסיון. ipsec statusall של strongSwan או יומן IKE של נתב אומר איזו הצעה הגיעה ואיזו נדחתה, והשוואה לזה עם ערכי ה-cmdlet היא הצעד היחיד שממש מוכיח ששני הקצוות הסכימו.
חיבור מוצלח אינו קו הסיום. פתחו את האפליקציה שחשובה למשתמש, כי מסלולים, DNS דחוף והגדרות מנהרה מפוצלת נכשלים אחרי שהמנהרה עולה ולא מייצרים שום דיאלוג שגיאה.
הפכו את זה לאוטומטי, וחזרו אחורה בצורה נקייה
התקנה ללא השגחה היא הסיבה לכתוב סקריפט לזה, ושלב החיוג הוא המקום שבו ההסמכות דולפות. rasdial לוקח אותן בשורת הפקודה שלו, שם משתמשים מקומיים אחרים ורוב אוספי היומנים יכולים לקרוא אותן:
subprocess.run(["rasdial", "Contoso L2TP"], check=True)העדיפו הסמכה המוגבלת לחשבון שמריץ את העבודה, או תנו לפרופיל לאחסן אותה עם -RememberCredential, במקום להעביר סיסמה כארגומנט במשימה מתוזמנת. פקודות האספקה עצמן בטוחות לחזרה עם -Force, אבל הן ישמחו לכסות הצעה ישנה, כך שהרצה חוזרת עוזרת רק אם הסקריפט נושא את הערכים הנוכחיים.
פרופילים נשמרים בין אתחולים וחיים יותר מהתצורה של השער שעבורו נבנו. כשההצעה של השער זזה, הסירו את הרשומה וצרו אותה מחדש במקום לשכב שכבה שנייה של ערכים מעליה: Remove-VpnConnection -Name "Contoso L2TP" -Force, ואז חזרו על שתי פקודות ה-cmdlet עם הקבוצה החדשה.
סגרו את הלולאה עם ארבע בדיקות שחיות לצד הסקריפט: Get-VpnConnection מציג את סוג המנהרה ורמת ההצפנה הצפויים; השער מתעד שלב 1 ושלב 2 שהושלמו לכתובת הלקוח שלכם; rasdial מחזיר הצלחה והאפליקציה נפתחת; וההצעה שנרשמה בסקריפט תואמת את הגדרת השער הנוכחית. כשמגיע ה-789 הבא, ההשוואה הזו לוקחת דקות במקום אחר צהריים.