strongSwan ESP-in-UDP: כשאין NAT לגלות

גילוי NAT מוצא תרגום כתובות, לא מדיניות חומת אש. חיבור אתר בלי NAT עדיין עלול לדרוש בחירה מפורשת של ESP-in-UDP.

גילוי NAT עונה על שאלה אחת: האם הכתובות או הפורטים השתנו בדרך? הוא אינו עונה אם חומת אש מתירה את פרוטוקול IP 50. שערי אתר בלי שום תרגום יכולים עדיין לעמוד מאחורי מדיניות שזורקת native ESP, ודרישה זו חייבת להיות מוגדרת ולא להתגלות. המנגנון הוא ESP-in-UDP, וזו החלטה, לא חלופה שמופיעה מעצמה.

הגילוי הוא אריתמטיקה על כתובות, לא בדיקת חומת אש

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

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

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

איך encap משנה את ההחלפה

בפריסת strongSwan מודרנית המנוהלת דרך swanctl.conf, ההגדרה encap = yes בחיבור משפיעה על החלפת גילוי NAT כך ששני הצדדים משתמשים בעטיפת UDP עבור ESP. החבילות המוגנות עוברות אז בתוך UDP, בדרך כלל בפורט 4500, ושני הקצוות חייבים להסכים על הסדר הזה.

connections {
    site {
        encap = yes
        # existing approved peer, authentication and child settings
    }
}

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

מדריך strongSwan ל-NAT-traversal מתאר את ההתנהגות הזו, כולל האינטראקציה עם פורט צף כשמשתמשים ב-MOBIKE.

השתמשו בהגדרה ששייכת ל-backend שלכם

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

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

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

אמתו את הנתונים העטופים, לא רק את הפורט

לכדו בשער בזמן שתעבורה מוגנת זורמת, ואז השוו זאת לתצוגה של strongSwan עצמו:

$ sudo tcpdump -ni eth0 'udp port 4500' -c 20
$ sudo swanctl --list-sas --ike site
$ sudo ip xfrm state list

native ESP מופיע כפרוטוקול IP 50 ואינו דומה ל-UDP כלל. ESP עטוף מופיע כדיוגרמות UDP על 4500 שהמטען שלהן אינו IKE. תעבורת IKE באותו פורט אינה הוכחה לעטיפה, כי MOBIKE יכול להעביר את IKE לשם בזמן שנתיב הנתונים נשאר native, אז קראו את המטען ולא את מספר הפורט.

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

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

מאמרים קשורים