Windows VPN Group24 מול MODP3072: איזו קבוצה אתם צריכים?
מספרי קבוצות הם רשומות רישום, לא דירוג לפי גודל. קשרו את השם לפרמטרים שלו, ואז בדקו אילו קבוצות פרמטר Windows יכול לבטא.
Group24 ו-MODP3072 הם שניהם שמות של קבוצת החלפת מפתחות, והם אינם אותה קבוצה בעוצמות שונות. Group24 משלב מודולוס של 2048 סיביות עם תת-קבוצה מסדר ראשוני של 256 סיביות, בעוד MODP3072 היא קבוצה 15 של 3072 סיביות. בחירה באחת כאשר השנייה צוינה משנה את הדרישה במקום למלא אותה. ארבעה דברים מכריעים את התוצאה, ואף אחד מהם לא דורש לסמוך על שם שנראה דומה.
המספר הוא רשומת רישום, לא דירוג
IANA ממספרת קבוצות החלפת מפתחות לפי סדר רישומן, ולכן מספר גדול יותר פירושו רשומת רישום מאוחרת יותר ולא קבוצה חזקה יותר. קבוצה 14 היא MODP של 2048 סיביות, קבוצה 15 היא MODP של 3072 סיביות, וקבוצה 24 משלבת מודולוס של 2048 סיביות עם תת-קבוצה מסדר ראשוני של 256 סיביות. קריאת המזהה כדירוג לפי גודל מייצרת בדיוק את הטעות של התייחסות ל-24 כאל 15 גדול יותר. השם הוא תווית, והפרמטרים שמאחוריו הם מה שהמשא ומתן באמת משתמש בו.
| IANA group | What the group is | Expressible as Windows DHGroup | What a mismatch looks like |
|---|---|---|---|
| 14 | A 2048-bit finite-field modulus | Group14 | The gateway reports modp2048, which is the same group in other vocabulary |
| 15 | A 3072-bit finite-field modulus | Not in the documented enumeration | You cannot request it from this parameter; a gateway reporting modp3072 was configured elsewhere |
| 24 | A 2048-bit modulus with a 256-bit prime-order subgroup | Group24 | The gateway reports modp2048s256, so the two names differ while describing one group |
| 20 | The NIST P-384 curve | ECP384 | The gateway reports ecp384, and that 384 counts a field size rather than a modulus |
קבוצות על עקום אליפטי מוסיפות בלבול משלהן, משום שמספר הסיביות של עקום מתאר שדה ולא מודולוס. השוואה של P-384 לקבוצת שדה סופי של 3072 סיביות כאילו המספרים מודדים דבר אחד אינה אומרת לכם דבר.
מה ספירת Windows יכולה לבטא
רישום IKE ופרמטר הלקוח של Windows הם ממשקים שונים עם אוצר מילים שונה. תיעוד ה-cmdlet של VpnClient של Microsoft מציין ש-DHGroup מקבל None, Group1, Group2, Group14, ECP256, ECP384 ו-Group24. Group15 אינו מופיע בקבוצה המתועדת הזו, כלומר הפרמטר אינו יכול לבטא את הקבוצה שהתבקשתם ממנה. זו מגבלה של הממשק ולא הצהרה על אילו קבוצות הפרוטוקול תומך.
אספקת איות שאינו ברשימה, מספר שלם או מחרוזת מדיניות מועתקת אינה מרחיבה את הספירה. בדקו את התיעוד עבור גרסת Windows שאתם באמת פורסים, ואם הקבוצה אינה זמינה, התוצאה הכנה היא מדיניות מאושרת אחרת או לקוח אחר.
הפרידו בין DHGroup, PfsGroup וסוג התעודה
DHGroup בוחר את הקבוצה עבור החלפת מפתחות IKE, ו-PfsGroup שולט בסודיות קדימה עבור אסוציאציות התעבורה המוגנת שבאות אחר כך. אלה שדות נפרדים, ולכן הגדרה נכונה של האחד אינה אומרת דבר על האחר. מפתח RSA או ECDSA של התעודה הוא מאפיין שלישי, והוא שייך לאימות ולא להחלפה האפמרלית. לכן פרופיל אחד יכול להיות נכון בשכבה אחת ושגוי באחרת, וחיבור מוצלח לא יגלה באיזו.
דוחות שסוג תעודה מסוים כפה קבוצת ECP בכל חיבור IKEv2 מתארים שילוב אחד של הגדרות. הם אינם קובעים כלל של הפרוטוקול, והתייחסות אליהם כאל כלל היא הדרך שבה מוזרות מקומית הופכת למדיניות.
קראו את הקבוצה שהשער ניהל משא ומתן עליה
מודול VpnClient מציע את Set-VpnConnectionIPsecConfiguration כממשק כתיבה בלבד, ואין Get- cmdlet מתאים שקורא את המדיניות הזו בחזרה במארח. רשמו את ערכי DHGroup ו-PfsGroup שהחלתם, ואז קראו בשער מה ההחלפה באמת השתמשה בו. הריצו את הפקודות אחרי חיבור חדש ולא אחרי התחברות מחדש שהשתמשה שוב באסוציאציה ישנה.
swanctl --list-sas
ipsec statusallפרופיל שמדווח Group24 בעוד השער מדווח modp2048s256 הוא עקבי, משום שאלה אותה קבוצה בשני אוצרות מילים. שער שמדווח modp3072 בעוד הפרופיל אומר Group24 אינו עקבי, וצד אחד אינו אוכף את מה שאתם חושבים. שורת התעודה עונה לשאלת האימות הנפרדת, ושדה PFS עונה לשלישית. השוו את שלושתם לפני כתיבת הערת תאימות.
רשמו את הקבוצה שהתבקשה, הקבוצה שנקבעה במשא ומתן והממשק שקיבל או דחה את ההגדרה. השלישייה הזו היא מה שסוקר צריך, ושום דבר ממנה לא ניתן להסיק משם המדיניות.