למה ל-Windows IKEv2 הנייטיבי אין בכלל שדה PSK

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

יכולת הפרוטוקול אינה תמיכת לקוח

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

אנשים בדרך כלל מגיעים אל הפניה של PowerShell להוספת חיבור VPN, ושם מוצג L2tpPsk עבור הסדר L2TP. הפרמטר הזה שייך ל-L2TP ואינו סוד IKEv2 כללי. הגדרות בחירת אלגוריתם בוחרות פרמטרי הגנה, שזה דבר שלישי ולא קשור. גם תפקיד הניתוב של Windows Server אינו אותו אובייקט. ממשק שרת יכול לכלול בקרות תצורה שאין לפרופיל לקוח שולחני, והעתקת הגדרת שרת לפרופיל תחנת עבודה אינה משחזרת את היכולת.

בחרו בין אישור, EAP או L2TP

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

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

בדקו מה השער יקבל

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

Get-VpnConnection -Name "Corp IKEv2" | Format-List AuthenticationMethod, TunnelType, EncryptionLevel, ServerValidation
Get-ChildItem Cert:\CurrentUser\My | Select-Object Subject, NotAfter

קראו את שיטת האימות של הפרופיל ואת מאגר האישורים יחד. פרופיל שמוגדר ל-EAP בלי אישור שמיש מאחוריו נכשל באופן שנראה כמו בעיית שרת.

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

תעדו את ההחלטה ואת הסודות

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

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