תשובות DPD מוכיחות שה-peer של IKE חי, ולא שהנתונים שלכם זורמים
תשובות חיות, הודעת ריפוד וסלקטורים מצומצמים מתארים שלושה דברים שונים. קראו אותם בנפרד לפני שאתם מאשימים אחד מהם בעצירה.
יומני IPsec יכולים להציג תשובות חיות בזמן שהאפליקציה שלפניהם תקועה, ושתי העובדות יכולות להיות נכונות בו־זמנית. תשובת DPD קובעת שעיבוד ה-IKE של ה-peer השיב באותו רגע; היא לא אומרת דבר על האם ה-SA הבן נושא את החבילה שחשובה לכם. התייחסות לכל אזהרה סמוך לתקלה כאל הסיבה שלה היא הדרך שבה בעיית סלקטור מאובחנת כבאג פרוטוקול. שלוש תצפיות מתבלבלות לרוב, והן עונות על שלוש שאלות שונות. קראו אותן לפי שיוך ומטרה לפני שאתם קוראים אותן לפי חותמת זמן.
מה כל תצפית מוכיחה
הטבלה מפרידה בין מה שכל תצפית קובעת לבין מה שהיא רק מלווה.
| Observation | What it establishes | What it leaves open |
|---|---|---|
| DPD replies arrive | The peer's IKE process answered | The child SA, forwarding path and application reply |
| TFC padding notification | The peer will not accept padding for that child SA | Whether ordinary ESP protection still works, which it does |
| Selectors reported as narrowed | The accepted traffic set is a subset of the offer | Whether the subset includes the flow the user needs |
אף אחת מהשלוש אינה שגיאה בפני עצמה. כל אחת נעשית מעניינת רק לצד הזרימה שאתם מדבגים, ושורה שאי אפשר לקשור לזרימה מסוימת היא הקשר ולא ראיה.
חיות אינה בריאות נתונים
DPD פועל כחילופי INFORMATIONAL, שיחה במישור הבקרה בין דמוני IKE. תשובה מוכיחה שתהליך ה-IKE של ה-peer נגיש ומוכן להשיב, ופסק זמן מוכיח שהוא לא. אף אחת מהתוצאות לא בוחנת את ה-SA הבן, את הסלקטורים, את נתיב ההעברה או את תשובת האפליקציה, ולכן DPD תקין לצד העברה תקועה הוא תמונה עקבית ולא סתירה.
לכן שורות החיות הן החלק הכי פחות שימושי בטיקט של מישור הנתונים, כמה מרגיעות שהן נראות בראש היומן.
הודעת הריפוד היא הצהרה על ריפוד
ריפוד TFC הוא השורה הנקראת יתר על המידה ביותר ביומנים האלה. היא אומרת שריפוד סודיות זרימת התעבורה לא יתקבל עבור ה-SA הבן הזה, וזו הצהרה על תכונת ריפוד אופציונלית ולא דחייה של הגנת ESP. מציאתה סמוך לכשל היא בדרך כלל מקריות של פירוט יתר, והדלקה או כיבוי של ריפוד לא משנים דבר בכיסוי הסלקטורים.
מפרט IKEv2 מגדיר גם את ההודעה וגם את משא ומתן הסלקטורים, ותווית אזהרה של מימוש אינה מחליפה את משמעות הפרוטוקול באף אחד משני המקרים.
צמצום שקט יותר וסביר יותר שחשוב
משיב רשאי לקבל תת־קבוצה של הסלקטורים המוצעים, והקבוצה המתקבלת יכולה להיות מודפסת על פני כמה רשומות, אחת מוסמכת לפי פורט ואחרת שמכסה את כל הפורטים. קריאה של השורה המוסמכת הראשונה בלבד מפחיתה את מה שהתקבל; קריאה של השורה הרחבה בלבד מגזימה בו. השוו את ההצעה המודפסת למדיניות המותקנת, כי ההצעה היא מה שהעמיתים אמרו והמדיניות היא מה שהקרנל יתאים. כשהן חלוקות, המנהרה קיימת והתעבורה לא, וזו התלונה התקופתית הקלאסית. הפכו את נקודת המבט המקומית והמרוחקת כשאתם משווים עמיתים, כי המקומי של כל צד הוא המרוחק של האחר.
רשומות ספציפיות למארח עם הגבלת פורט שוות קריאה כפולה, כי הן אלה שמחריגות ICMP או פורט שני בזמן שפינג לשער ממשיך לעבוד.
בנו רשומה אחת עבור הזרימה שנכשלת
תעדו מקור, יעד, משפחת כתובות, פרוטוקול ופורט כפי שהם נראים בהחלטת ההגנה, כולל כל תרגום מכוון. אלה הערכים שחייבים להתאים לסלקטור, ואלה גם הערכים שאנשים מקלידים מחדש מהזיכרון כשהטיקט מגיע לזוג ידיים שלישי.
לאחר מכן זהו את ה-SA הבן ואת מוניו הכיווניים: swanctl --list-sas נותן את סיכום השיוך במארח strongSwan, ו-ip -s xfrm state נותן את המונים. קראו אותם לאחר בקשה מורשית טרייה ולא כשהמערכת בהמתנה. היעדר עלייה ביציאה מצביע על בחירה או על הנתיב המקומי; יציאה בלי כניסה מתאימה מצביעה על ה-peer, על ההעברה שלו או על התשובות שלו.
חילופי אפליקציה שהושלמו גוברים על כל אחד מהמונים, ולכן הבדיקה צריכה להסתיים באפליקציה ולא במחוון המנהרה.
בחרו את התיקון לאחר מכן
רק לאחר שהרשומה הזו קיימת יש תיקון לבחור: סלקטורים שהתקבלו, מסלול, סינון, מימוש של ה-peer, או גבול שהדגמתם עכשיו. איפוס ה-peer משנה כמה מצבים בבת אחת ולעיתים קרובות משחזר תעבורה בלי להסביר איזה מהם היה שגוי, ולכן התקלה חוזרת. השאירו דאמפים של מצב הקרנל מחוץ לטיקטים, כי הם יכולים להכיל מפתחות והסיכום הצר מספיק לכל מי שצריך לעזור.
כשהרשומה סותרת את התאוריה הראשונה שלכם, האמינו לרשומה וכתבו את התאוריה מחדש; ההרגל הזה שווה יותר מכל שורת יומן בודדת שנדונה כאן.