strongSwan על EC2: תנו ל-VPC לנתב את עומס העבודה

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

תחילה רשמו את ארבע הכתובות

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

VPC:             10.60.0.0/16
Gateway subnet:  10.60.1.0/24, gateway ENI address 10.60.1.10
Workload subnet: 10.60.2.0/24, application address 10.60.2.20
Remote network:  10.90.0.0/24

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

שלב 1: תנו לתת-הרשת של עומס העבודה מסלול

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

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

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

שלב 2: הפעילו העברה באורח

sysctl -w net.ipv4.ip_forward=1
# persist in /etc/sysctl.d/ and re-apply after reboot

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

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

שלב 3: הרחיבו את הבוררים למקורות האמיתיים

מדיניות שמכסה בצד AWS רק את 10.60.1.10/32 מסבירה הצלחה שהחלה בשער בלי לכסות את 10.60.2.20. מסלול אל היעד המרוחק אינו מרחיב בורר תעבורה, וזה החצי השני של אותה הפתעה.

swanctl --list-sas
# read the installed CHILD-SA local and remote traffic selectors

אם התכנון המוסכם מגן על ה-VPC כולו, שני הצדדים חייבים לקבל את 10.60.0.0/16 ואת 10.90.0.0/24. אם הוא מגן על עומס עבודה אחד, השתמשו במכוון בקידומת הצרה יותר. בכל מקרה, בדקו את מדיניות CHILD-SA המותקנת, משום שתצורה שערכתם וצד שצמצם אותה אחרת אינם אותו הסכם.

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

שלב 4: אמתו, ואז חזרו אחורה אם צריך

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

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

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