מנהרה מלאה ב-strongSwan דורשת 0.0.0.0/0 בשני הצדדים

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

בדקו קודם את הבורר של הלקוח

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

children {
    net {
        local_ts  = dynamic
        remote_ts = 0.0.0.0/0
    }
}

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

בדקו את הבורר של השער בצד שלו

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

children {
    rw {
        local_ts  = 0.0.0.0/0
        remote_ts = 10.77.0.0/24
    }
}

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

ה-ipsec.conf הישן משתמש בתפקידי שמאל וימין עם מפתחות שונים, ושורת rightsubnet אינה החלפה ישירה של ערך swanctl. החזיקו את שתי התחבירים בקבצים נפרדים במקום להדביק אחד בתוך השני. ערבוב שלהם באותה תיקייה הוא הדרך שבה חיבור עובד חוזר בשקט לאחר אתחול.

בדקו את ה-child SA שנדון, לא את הקובץ

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

swanctl --list-conns
swanctl --list-sas
ip xfrm policy list

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

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

בדקו את ההעברה ואת מסלול החזרה

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

sysctl net.ipv4.ip_forward
iptables -t nat -S | grep -i masq
ip route get 1.1.1.1

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

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

בדקו מה המנהרה עדיין לא מכסה

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

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

resolvectl query intranet.example.internal
traceroute -n 1.1.1.1

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