IKEv2 אינו חילוף אחד: IKE SA, אימות, ואחר כך CHILD SA
תשובת השער מוכיחה נגישות, לא זהות. עקבו אחרי IKE_SA_INIT, IKE_AUTH וה-CHILD SA הראשון, ואז בדקו מה חייב להתקיים לפני שהתעבורה עוברת.
אתם עשויים לחשוב שחיבור IKEv2 הוא חילוף אחד שנגמר בתעבורה מוצפנת. יש לפחות שניים, והראשון אינו מאמת אף אחד. הצדדים מתחילים בהודעות בקרה, מסכימים על פרמטרים קריפטוגרפיים, מוכיחים זהות ורק אז מנהלים משא ומתן על המצב שנושא את חבילות היישום. הסדר הזה מסביר את אי-ההתאמה שאנשים מדווחים עליה כל הזמן: השער עונה, הלקוח אומר שמחובר, והיישום הפרטי עדיין מגיע לפסק זמן. הנה מה שכל שלב באמת עושה, ומה חייב להתקיים אחריו.
המיתוס: אם השער עונה, אתם מחוברים
תשובה להודעה הראשונה מוכיחה שנקודת הקצה נגישה ומוכנה לדבר. היא אינה מוכיחה שחשבון התקבל, ששרשרת תעודות אומתה, או שמדיניות נתונים כלשהי הותקנה.
הכשלים האלה קורים מאוחר יותר, והם מייצרים תסמינים שונים. דחיית תעודה או כשל EAP מגיעים אחרי שהחילוף הראשון כבר הצליח, ולכן פינג ל-UDP 500 וסמל ירוק בלקוח אומרים כל כך מעט.
IKE_SA_INIT: להסכים על פרמטרים, לא על זהות
החילוף הראשון נושא את ההצעות עבור איגוד האבטחה של IKE: אלגוריתמי הצפנה ושלמות, פונקציה פסאודו-אקראית וקבוצת Diffie-Hellman. הצדדים מחליפים גם nonces, וכל צד גוזר חומר מפתח ל-IKE SA מהסוד המשותף שהערכים האלה יוצרים. שום דבר בחילוף הזה לא קובע מי הצד השני. הוא קובע ששני הצדדים יכולים לחשב את אותם מפתחות ושהם מסכימים על הצעה. מגיב שלא אוהב שום הצעה דוחה כאן את החילוף, ולכן אי-התאמה בגרסה או באלגוריתם נראית כמו שרת שנפל.
ה-IKE SA שנוצר בנקודה זו מגן על כל חילופי הניהול המאוחרים. זה התפקיד שלו, וזה תפקיד שונה מהגנה על החבילות שלכם.
IKE_AUTH: להוכיח זהות, ואז לבנות את ה-CHILD SA הראשון
החילוף השני נושא זהות. עם תעודות, כל צד חותם במפתח הפרטי שלו ומציג שרשרת שהצד השני חייב לאמת; עם EAP, המגיב מאתגר את היוזם באמצעות השיטה שנבחרה. כאן סוף סוף עולים שם שרת שגוי, תעודה שפגה או סיסמה שנדחתה.
במקרה הרגיל IKE_AUTH מנהל משא ומתן גם על ה-CHILD SA הראשון, כך שהגנת הנתונים מוסכמת באותו מחזור הלוך ושוב. היוזם מציע בוררי תעבורה, המגיב מצמצם או דוחה אותם, והמפתחות לנתיב הנתונים נגזרים מה-IKE SA. זה אומר שחילוף אחד יכול להיכשל בשני מקומות שונים מאוד: זהות או מדיניות. קראו את מטען ההתראה או את השגיאה ולא את כשל לחיצת היד הכללי, כי התיקון לאחד הוא תעודה והתיקון לשני הוא אי-התאמת תת-רשת.
שני SA, שני תפקידים
| איגוד | מגן על | התנהגות תוחלת חיים |
|---|---|---|
| IKE SA | חילופי ניהול: חידוש מפתחות, מחיקה, מטעני תצורה | מחודש לפי לוח הזמנים שלו; נתיב הנתונים יכול לשרוד את השינוי |
| CHILD SA | תעבורת יישום שמתאימה לבוררי התעבורה | מחודש באופן עצמאי, לעתים קרובות יותר |
החזקתם בנפרד מסבירה שני התנהגויות שנראות כמו באגים. מנהרה יכולה להיראות מוקמת בזמן שחידוש מפתחות נכשל ברקע, ו-CHILD SA יכול להיות מוחלף בלי שהלקוח יאבד את החיבור.
ב-strongSwan, תיעוד התצורה של IKEv2 ו-swanctl --list-sas מציגים את שתי הרמות, ו-ip xfrm state יחד עם ip xfrm policy מציגים מה הגרעין באמת התקין. השוואה בין שתי התצוגות היא הדרך המהירה ביותר לראות אם המשא ומתן הסתיים או רק נראה שהסתיים. אם הדמון מפרט CHILD SA שלגרעין אין מצב עבורו, ההתקנה נכשלה בשקט. אם לגרעין יש מצב שהדמון לא מכיר, אתם רואים שארית של ניסיון קודם.
מה עוד חייב להתקיים אחרי שהמנהרה עולה
בוררי התעבורה מגדירים אילו כתובות מכוסות. אם הלקוח מציע תת-רשת אחת והשרת מצפה לאחרת, ה-CHILD SA מותקן אבל לא נושא שום דבר שימושי, והשגיאה מופיעה כבעיית ניתוב ולא כבעיית משא ומתן. אחר כך על המחסנית המקומית לשתף פעולה: העברה מופעלת היכן שהמארח מנתב, נתיבים שמצביעים למנהרה, כללי חומת אש שמתירים את החבילות שנפתחו מקיפוס, ומפענח פנימי אם מעורבים שמות פרטיים. כל אחד מאלה נכשל בנפרד ואף אחד מהם לא מתוקן בהפעלה מחדש של דמון ה-IKE.
השאירו את היומן גלוי בזמן האבחון: החילוף הראשוני, אחר כך אימות זהות, אחר כך אימות משתמש היכן שרלוונטי, אחר כך התקנת CHILD ולבסוף תעבורת היישום. השלב שנעצר הוא השלב לתקן, וכשל ניתוב מאוחר הוא לעולם לא סיבה להקל בבדיקות הזהות שכבר עברו.