למה מנהרת IPsec עמוסה מחליפה מפתחות מוקדם: מגבלות זמן מול נפח

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

ספרו את מה שהאגודה סופרת, לא את הממשק

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

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

סף רך וסף קשיח הם שני אירועים שונים

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

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

קראו את תוחלת החיים האפקטיבית ממצב הריצה

ב-strongSwan, swanctl --list-sas מדפיס את סיכום האגודה עם זמני החלפת המפתחות והחיים, כך שהערך שהדמון מתכוון לאכוף גלוי בלי ניחושים. במארח Linux בלי תצוגת דמון, ip xfrm state מדווח את מגבלות הבתים והמנות הרכות והקשיחות שהוגדרו לצד המונים הנוכחיים. שתי הקריאות האלה עונות על שאלות שונות ושתיהן שוות שמירה בכרטיס.

swanctl --list-sas
ip -s xfrm state

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

עקבו אחרי החילופין שמחליף את ה-SA

הפרידו בין שלושת החידושים, כי הן נכשלות בדרכים שונות: החלפת מפתחות של IKE SA בונה אגודת בקרה חדשה, החלפת מפתחות של CHILD SA מחליפה את אגודת הנתונים, ואימות מחדש חוזר על חילופי הזהות. ב-IKEv2 כל עמית מחליט על תוחלות החיים שלו במקום לנהל משא ומתן על ערך משותף אחד, ולכן חילופין שלא יזמתם הוא דבר רגיל. אי-התאמה ב-perfect forward secrecy היא סיבה נפוצה למותה של child SA חדשה בדיוק במרווח החלפת המפתחות, והיא נראית בדיוק כמו תקלת טיימר עד שמישהו קורא את ההצעה.

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

הוכיחו את החידוש במקום להסתיר אותו

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

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