איך IPsec מבוסס נתיבים עובד עם ממשק XFRM

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

מה ההתקן הוא ומה הוא לא

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

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

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

בנו אחד בסדר הנכון

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

העלו את ההתקן, ואז אשרו את המזהה שהקרנל רשם לפני שתיגעו בקונפיגורציית ה-VPN:

sudo ip link add xfrm0 type xfrm dev eth0 if_id 42
sudo ip link set xfrm0 up
ip -d link show xfrm0 | grep -o 'if_id [0-9]*'

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

הרחיקו את IKE ו-ESP מנתיב המנהרה

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

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

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

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

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

קראו את שניהם, ואז קראו את תפיסת הדיימון את אגודת הילד:

ip -s link show xfrm0
sudo ip xfrm state list | grep -E 'src|proto|mode'
sudo swanctl --list-sas

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

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

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

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

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