נתיב ברירת המחדל של XFRM בלע את IKE ו-ESP: שמרו על הנתיב החיצוני

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

שני היעדים המעורבים אינם ניתנים להחלפה. הניתוב חייב לומר זאת במפורש.

לאן באמת הולך החיפוש אחר העמית

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

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

ip rule show
ip route show table 220
ip -4 route get 198.51.100.44 from 10.40.0.2
ip xfrm policy list

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

אפשרויות החרגה בשער מודרני

התיעוד של strongSwan על VPN מבוסס ניתוב מציג שתי תשובות מעשיות. האחת מסמנת IKE ו-ESP כדי שהכלל שמצביע על טבלת XFRM לא יתאים להן. האחרת משאירה נתיב עמית או החרגה שהחיפוש עדיין יכול להגיע אליהם.

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

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

הסימון הוא ביט אחד ב-fwmark של החבילה ששום דבר אחר בשער לא תובע: 0x1 עם מסכה 0x1 היא הבחירה הרגילה, והוא חייב להיות מוגדר בשני מקומות כדי שההחרגה תעבוד. Charon צריך אותו על שקע IKE, והגדרות הסימון הנכנס והיוצא של חיבור הילד צריכות את אותו ערך כדי שגם חבילות עטופות ייצאו מסומנות. מסכה של 0x1 במקום 0xffffffff משאירה את הביטים הנותרים חופשיים, וזה חשוב כשמערכת משנה אחרת כבר מסמנת חבילות באותו מארח. כששניהם מוגדרים, הכלל נכתב כהחרגה, כך שחבילות מסומנות מדלגות על הטבלה שמחזיקה את נתיב XFRM ונופלות לטבלה הראשית:

ip rule add not fwmark 0x1/0x1 lookup 220 pref 1000
ip -4 route get 198.51.100.44 from 10.40.0.2 mark 0x1

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

מה ההתקנה האוטומטית מניחה על הבנייה

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

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

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

עקבו אחרי החידוש הראשון

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

ip -4 route get 198.51.100.44
sudo swanctl --list-sas
sudo tcpdump -ni any 'udp port 500 or esp'

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

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