GDOI: מדוע שרת המפתחות אינו בנתיב הנתונים שלכם

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

שני סוגי מצב אבטחה

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

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

עקבו אחר החילופים, לא אחר התרשים

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

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

שלושה רשומות ששווה לשמור

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

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

ממשק, חיבור שירות, נתיב עיבוד

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

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

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

זמינות הבקרה והעברת הנתונים הן בדיקות נפרדות

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

אחר כך בדקו את ההעברה בנפרד, כשהבקר מחוץ לתמונה. שתי בדיקות, שתי תוצאות, ווויכוח קצר בהרבה על איזו מחצית שבורה.