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

עברו עליהם לפי הסדר ועצרו בראשון שנכשל.

מה הממשק מוסיף לתמונה

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

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

קראו את ארבעת המצבים לפני שמאשימים את המנהרה

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

ip -s link show xfrm0
ip route get 10.20.30.40
ip xfrm state
ip xfrm policy
swanctl --list-sas
tcpdump -ni xfrm0 -c 20 host 10.20.30.40

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

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

השוו את המונים הפנימיים למונים החיצוניים

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

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

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

עקבו אחרי זה דרך חידוש מפתחות ומעבר כשל

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

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

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

מאמרים קשורים