IKEv1 עם XAuth ו-OTP: מה כל שדה מבקש
PSK קבוצתי, חילוף XAuth של משתמש ואתגר OTP הם שלושה קלטים שונים. התאימו כל שדה לבעלים שלו לפני התקנת לקוח נוסף.
IKEv1 עם PSK, XAuth ו-OTP אינו מבקש סיסמה מורכבת אחת. הוא משכיב מפתח משותף בין העמיתים, חילוף משתמש וגורם שני שהבקאנד מחליט כיצד לבקש. לכל שכבה הבעלים שלה והודעת הכשל שלה. ערבוב ביניהם גורם לאנשים להקליד מחדש קוד חד-פעמי בשדה שמאחסן סוד קבוצתי.
התאימו כל שדה לשכבה שמבקשת אותו לפני התקנת לקוח נוסף או איפוס אישור.
שלושה סודות, שלושה בעלים
המפתח המשותף מראש שייך ליחסי העמיתים ומוגדר פעם אחת על ידי מי שמחזיק בשני הקצוות. אישור המשתמש שייך לבקאנד האימות ומאומת בכל התחברות. הגורם השני שייך למערכת טוקנים שתגובתה משתנה בכל ניסיון. אף אחד אינו מחליף אחר, ופריסה שמתייחסת אליהם כאל סיסמה אחת נכשלת בשכבה שאיש לא תיעד.
רשמו שלושה עמודות: בעלים, תוחלת חיים והודעת הכשל שכל אחד מפיק. הטבלה הזו היא כלי האבחון, ולא שמות השדות בלקוח.
| Layer | Owner | Lifetime |
|---|---|---|
| Pre-shared key | Peer configuration | Until operators change it |
| XAuth credential | Authentication backend | Per session, per policy |
| One-time code | Token system | Single use |
PSK: העמית, לא האדם
המפתח המשותף מראש מאמת את צמד השערים בסידור הישן הזה, ולכן התחברות המשתמש לעולם אינה מחליפה אותו. הוא גם הערך שסביר ביותר שיהיה שגוי באופן שמייצר שגיאת משא ומתן כללית במקום שדה. כאשר המנהרה נכשלת לפני שמופיע שדה משתמש כלשהו, החשודים הם המפתח או ההצעות.
אישור משתמש אינו יכול לתקן כשל בשלב הראשון. החלפתו מבזבזת את האישור היחיד שאפשר להחליף בבטחה, ומחזקת את התיאוריה השגויה.
XAuth: חילוף המשתמש הישן
XAuth מוסיף חילוף אימות משתמש מעל אימות העמית של IKEv1, והשער מחליט איזה בקאנד מאמת אותו. בהתאם לבקאנד הזה, החילוף עשוי לקבל סיסמת מדריך, אישור RADIUS או תגובת טוקן. המילה XAuth משמשת שם להובלה של החילוף, לא לסוג האישור.
בדקו לאיזה בקאנד מצביע פרופיל השער. זה אומר לכם מה יישאל מהמשתמש ומה איפוס סיסמה באמת משנה, ואף אחד מהשניים אינו נראה בפרופיל לקוח.
OTP: מה שהבקאנד יבקש
פריסות מסוימות מבקשות קוד חד-פעמי נפרד אחרי הסיסמה, ואחרות מגדירות פורמט קלט משולב עם מפריד מתועד. שניהם קיימים, והפרופיל שלפניכם מחליט איזה. להמציא שרשור כי הוא עבד באתר אחר היא הדרך הנפוצה ביותר לשרוף טוקן רישום. התיעוד של השער עצמו הוא המקור היחיד שמכריע בכך.
השתמשו בפורמט המתועד עם לקוח שיכול להשלים את החילוף שהשער מציע.
היכן גבול הלקוח נושך
Fortinet מתעדת ש-FortiClient 7.4.4 וגרסאות מאוחרות יותר אינן תומכות עוד ב-IKEv1 עבור VPN של IPsec, וזה גבול מוצר וגרסה ולא הסרה גורפת, כפי שהערת התאימות של FortiClient מתעדת. גם לקוחות אחרים אינם ניתנים להחלפה: OpenConnect ו-openfortivpn מדברים פרוטוקולי שער מסוימים, לא פרופילי IKEv1 שרירותיים. בדקו בנפרד את גרסת IKE, מצב PSK, תמיכת XAuth ומודל האינטראקציה של הלקוח המותקן. לקוח שמתחבר בשיטה אחרת לא הוכיח את הדרישה המקורית.
IKEv1 מיושן, ולכן פריסה חדשה על לקוח ישן ללא תמיכה היא פתרון קצר מועד. בקשו מבעל השער מסלול הגירה נתמך, כולל כיצד יטופל שם הגורם השני.
אבחון בלי לכבות את הגורם
הפרידו את השלבים ביומן: משא ומתן עמיתים, חילוף המשתמש, תוצאת הגורם השני, ואז הקצאת כתובת ומסלול. רשמו את הרכיב והשלב במקום לנסות את הקוד בכל שדה. כיבוי הגורם כדי שמבחן יעבור מייצר מנהרה שלא מוכיחה דבר על הפריסה.
שמרו סודות רישום ואת המפתח המשותף באחסון מוגן לפי התהליך של הארגון. קוד חד-פעמי בקובץ מתמיד הוא גורם שהפסיק להיות כזה.