Add-VpnConnection: למה ה-PSK נשבר ולמה הכתובת נשארת
PowerShell מרחיב מפתח משותף מראש בתוך מרכאות כפולות לפני שה-cmdlet שומר אותו, ומנהרה פעילה שומרת את הכתובת הישנה עד שתתחברו מחדש.
פרופיל VPN של Windows הוא רשומה בספר טלפונים, ו-PowerShell היא דרך אחת לערוך את הרשומה הזו. מההבחנה הזו נובעות שתי תקלות: מפתח משותף מראש שמגיע לשרת כשהוא כבר פגום, וכתובת שרת שנראית מעודכנת אך אינה זו שאליה תחייג המנהרה הבאה. את שתיהן קל יותר לראות כשמתייחסים לפרופיל כאל מצב שמור ולא כאל פקודה שהרצתם. הסיור עוקב אחר סדר העריכות: יצירה, שינוי, היקף, קריאה חוזרת.
בונים את הפרופיל עם מפתח מילולי
Add-VpnConnection מקבל את מפתח L2TP המשותף מראש דרך -L2tpPsk. PowerShell מעבד את המחרוזת לפני שה-cmdlet מקבל אותה, ובתוך מרכאות כפולות סימן דולר פותח הפניה למשתנה בעוד ש-backtick פותח בריחה. מפתח שמכיל אחד מהשניים מגיע קצר יותר, או עם תו אחר, והפרופיל נוצר בהצלחה עם הסוד הלא נכון.
אחר כך התקלה מופיעה באימות IPsec, שם המנהרה מסרבת לעלות. לכן שגיאת מרכאות מדווחת לעיתים כה קרובות כבעיה בצד השרת: הפרופיל קיים, השם נכון, והסוד פשוט שגוי בשקט.
| How you write it | What PowerShell does | Result |
|---|---|---|
| "p@ss$word!42" | Expands $word as a variable | Stored key is truncated |
| Double-quoted with an escape character | Consumes the next character as an escape | One character disappears |
| 'p@ss$word!42' | Keeps the literal characters | Stored key matches the secret |
מרכאות בודדות הן הפתרון, והן חייבות להקיף את כל הערך. אם הרשומה כבר קיימת עם מפתח גרוע, -Force מחליף אותו, או הסירו וצרו את הפרופיל מחדש ואז בדקו בחיבור חדש:
Add-VpnConnection -Name "Contoso-L2TP" -ServerAddress vpn.contoso.example -TunnelType L2tp -L2tpPsk 'n3w$ecret!2026' -AuthenticationMethod Pap -RememberCredential -Forceהרחיקו את הסוד האמיתי מהיסטוריית ה-shell ומסקריפטים משותפים. קראו אותו בזמן ריצה מהמחסן המאושר והעבירו את המשתנה במקום את הערך המילולי, מה שנמנע לחלוטין מבעיית המרכאות.
משנים את הכתובת ואז מתחברים מחדש
Set-VpnConnection מקבל פרמטרים מופרדים ברווחים, לא תחביר השמה. כתיבת -ServerAddress = "203.0.113.10" מעבירה אסימון נוסף, וה-cmdlet או נכשל או שומר משהו שלא התכוונתם לו. הצורה הנכונה היא -Name "Office L2TP" -ServerAddress 203.0.113.10.
גם עם התחביר הנכון, השינוי לא מגיע למנהרה שכבר למעלה. חיבור שקיים שומר את הכתובת שאליה חייג עד שינותק, ולכן בדיקת אותו מושב אינה מוכיחה דבר על הערך החדש. התנתקו, ערכו, התחברו מחדש, ואמתו את כתובת העמית בפרטי החיבור.
יש מאפיינים שאי אפשר לשנות במקום. כשה-cmdlet מסרב, רשמו את הפרמטרים הקיימים, מחקו את הפרופיל וצרו אותו מחדש עם הערכים המתוקנים, ושמרו על הגדרות המנהרה והאימות המקוריות. סקריפט שצריך לשנות רק את מספר הטלפון יכול לערוך את רשומת ספר הטלפונים דרך RAS API במקום ליצור הכול מחדש. בכל מסלול שתבחרו, אמתו אחר כך את הערכים השמורים ולא תסמכו על שתיקת הפקודה.
לדעת איזה ספר טלפונים ערכתם
פרופיל לכל משתמש חי בתיקיית חיבורי הרשת של אותו משתמש, ופרופיל לכל המשתמשים חי בתיקייה ברמת המכונה תחת עץ נתוני התוכניות. אלו רשומות שונות עם היקפים שונים, ועריכת האחת משאירה את האחרת ללא פגע.
לכן שינוי יכול להיראות כאילו נעלם: הסקריפט רץ בחשבון אחד והבדיקה באחר. השתמשו ב--AllUserConnection כשהפרופיל שייך למכונה, ובדקו את אותו היקף כשאתם קוראים אותו חזרה.
קוראים את הפרופיל חזרה לפני הבדיקה
שאלו את Windows מה הוא שמר ולא מה העברתם:
Get-VpnConnection -Name "Office L2TP" | Select-Object Name, ServerAddress, TunnelType, AuthenticationMethodהשוו את הפלט הזה לכוונה, ואז התחילו חיבור חדש. אם החיוג נכשל, בדקו את יומן לקוח RAS במציג האירועים לפני שתשנו את הפרופיל שוב, כי היומן נוקב בשם השלב שנכשל.
שמרו על תכנון האימות שלם בזמן העריכה. פקודה שמשנה את הכתובת אך מפילה את האישור או את תצורת EAP יוצרת תקלה שנראית לא קשורה לעריכה, וייצוא הפרופיל העובד מראש נותן לכם משהו לשחזר במקום ניחוש.