למה מסלול OpenVPN מפסיד למדיניות XFRM של strongSwan

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

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

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

בורר IPsec רחב הוא הסיבה הרגילה. מדיניות שמגנה על 172.16.0.0/12 מכסה גם את 172.20.8.0/24, שאליו מנהל עשוי להתכוון להגיע דרך מנהרת OpenVPN במקום. הכוונה קיימת רק בטבלת הניתוב, ומסד המדיניות מעולם לא ידע עליה.

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

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

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

ip rule show
ip route show table all
ip route get 172.20.8.20 from 10.44.7.15

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

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

קראו גם את המדיניות שחלה

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

ip -s xfrm policy
swanctl --list-sas

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

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

שלוש אפשרויות כששני הנתיבים לגיטימיים

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

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

connections {
    openvpn-exception {
        remote_addrs = 127.0.0.1
        children {
            openvpn-exception {
                local_ts = 10.44.7.0/24
                remote_ts = 172.20.8.0/24
                mode = pass
                start_action = trap
            }
        }
    }
}

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

הוכיחו את החריגה בלי להחליש את השאר

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

תעדו איזו קידומת משתמשת באיזה נתיב ולמה. אחרת המהנדס הבא שיראה בורר רחב יפתח מחדש את אותה חקירה, והתשובה תשב בהודעת commit שאיש לא קורא.