ESP הגיע אבל שום דבר לא פוענח? עקבו אחר שלבי הקליטה

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

ההגעה היא תצפית אחת, לא שלוש

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

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

חיפוש האסוציאציה מתרחש לפני הפענוח

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

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

בדיקות שידור חוזר ושלמות דוחות לפני שקיים מטען

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

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

פורט UDP 4500 הוא מכל, לא פסק דין

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

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

רק אחרי החילוץ חלים ניתוב ומדיניות

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

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

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