IPsec עם כמה תת-רשתות מאבד את תעבורת החזרה? ספרו את ה-reqid

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

הפרידו את התסמין לפני שמשנים משהו

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

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

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

בלינוקס רשומות המדיניות קובעות את ההצפנה, ולכן מדיניות תואמת, ולא נתיב, היא שמכניסה חבילה למנהרה. הריצו ip xfrm policy כדי לראות את הבוררים, הכיוון, העדיפות והתבנית של כל רשומה, ו-ip xfrm state כדי לראות את ההתאמות שהוקמו עם ה-reqid שלהן. המדיניות וההתאמה מחוברות באמצעות אותו reqid.

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

האסימטריה הקלאסית: reqid אחד לכמה תת-רשתות

כשל נפוץ מגיע מעמית שמתקין מדיניות לכל תת-הרשתות שנדונו תחת reqid יחיד, מה שקורה עם generate_policy require של racoon. התעבורה יוצאת אז דרך ההתאמה שהוקמה אחרונה, בעוד הצד השני מחזיק התאמה נפרדת לכל תת-רשת. התשובות מגיעות על התאמה שה-reqid שלה אינו מזהה את המדיניות שאמורה לקבל אותן, והגרעין משליך אותן לאחר הפענוח.

התיקון הוא שינוי תצורה, לא כלל חומת אש: generate_policy unique; נותן לכל מדיניות reqid משלה, כך שלהתאמות של העמית לכל מדיניות יש שותפים תואמים. הפעילו אותו, נהלו משא ומתן מחדש, וספרו את ה-reqid השונים עבור תת-הרשתות שאתם מצפים להן לפני הצהרת הצלחה.

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

הבוררים מגיעים מהמשא ומתן, לא מהתצורה שלכם

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

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

אמתו לפי הסדר הזה, ודעו איך לחזור אחורה

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

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