למה מדיניות אבטחה של IPsec אינה רשומה בטבלת הניתוב

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

התחילו בחיפוש, לא בטבלה

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

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

התאימו את הבוררים בשני הצדדים

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

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

התאמת מדיניות אינה מצב מותקן

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

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

מה מנהרה מבוססת מסלול עדיין דורשת

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

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

הבהירו בעלות לפני שעורכים משהו

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

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