IKEv2 כתובת שרת לעומת זהות: מה שהלקוח בודק בפועל

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

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

ראשית, איזה ערך הוא הכתובת

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

במונחים של strongSwan, הכתובת היא right או left, והזהות הצפויה היא rightid או leftid, וזה מה שמתאר תיעוד התצורה של IKEv2. אם רק אי פעם ערכת את הכתובת, הגדרת חצי מהזוג.

שנית, מה התעודה יכולה להוכיח

לזהות יש סוג, ועל האישור לשאת שם תואם. זהות DNS מסופקת על ידי ערך dNSName בסיומת השם החלופית של הנושא; זהות IP זקוקה לערך iPAddress. תעודה שהוצאה עבור vpn.example.com אינה מוכיחה דבר על הכתובת המילולית 203.0.113.10, ואישור שניתן עבור כתובת זו אינו מוכיח דבר על השם. לפיכך, הנפקה מחודשת לשם אחר אינה תחליף נפילה, גם כאשר נעשה שימוש חוזר באותו מפתח ו-CA.

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

שלישית, איך כל לקוח מציין את הציפייה

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

ב-strongSwan הציפייה מפורשת: הגדר את rightid לזהות שהשרת מציג בפועל, אשר עשויה להיות שונה מימין. הגדרתו ל-%any מקבלת את כל מה שהעמית מציע ומסירה בדיוק את ההמחאה שאתה מנסה לשמור.

רביעית, הפרד את התחברות המשתמש מזהות עמיתים

EAP אימות וזהות השרת עונים על שאלות שונות. זהות EAP כגון [email protected] אומרת מי המשתמש, לאחר שהלקוח החליט שהשרת הוא הנכון. סיבוב הסיסמה לא יכול לתקן אי התאמה של זהות עמיתים, מכיוון שהחיבור לעולם לא מגיע לשלב הכניסה של המשתמש.

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

חמישית, שנה אותו דרך ערוץ מאומת

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

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