מדיניות IKEv2 מותאמת ב-Windows: החל אותה כשלב נפרד

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

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

שני סוגי מדיניות מאחורי שמות דומים

Windows מפריד בין המדיניות שמגנה על חילופי המפתחות לבין המדיניות שמגנה על התעבורה. צד IKE מוגדר באמצעות שיטת הצפנה ושיטת שלמות. צד הנתונים מוגדר באמצעות קבועי צופן וקבועי טרנספורמציית אימות, והקבועים האלה משתמשים בשמות משלהם. תווית AES אחת שהועתקה לשדה הלא נכון יוצרת חיבור שנוצר תחת מדיניות שאיש לא אישר.

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

בנו מדיניות מלאה, לא שני שמות של אלגוריתם

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

$policy = @{
    ConnectionName = 'Corp IKEv2'
    AllUserConnection = $true
    EncryptionMethod = 'AES256'
    IntegrityCheckMethod = 'SHA384'
    CipherTransformConstants = 'AES256'
    AuthenticationTransformConstants = 'SHA384128'
    DHGroup = 'Group19'
    PfsGroup = 'PFS2048'
    Force = $true
}
Set-VpnConnectionIPsecConfiguration @policy

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

צרו קודם, ואז החילו — בתחום אחד

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

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

השדות המתועדים של Configuration Designer מתארים הגדרת VPN אחת ואינם חושפים כל בקרת IPsec מקורית. אם הדרישה היא אספקה מנוהלת, לספק שירות התצורה VPNv2 יש סעיף מערך הצפנה בדיוק למטרה הזו.

מנו בעלים אחד למדיניות

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

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

אמתו את התוצאה שנקבעה במשא ומתן, לא את החבילה

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

Get-VpnConnection -Name 'Corp IKEv2' -AllUserConnection | Format-List
Get-ChildItem 'C:\ProgramData\Microsoft\Network\Connections\Pbk' | Select-Object Name, LastWriteTime

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