מ-strongSwan אל AWS Site-to-Site: מדוע ה-Child SA אינו בוחר דבר

מנהרת IKE יכולה להיות פעילה בעוד אסוציאציית הבן מוציאה את תת-הרשתות שלך. השווה קודם את ה-CIDR המקומי והמרוחק ב-AWS עם leftsubnet ו-rightsubnet.

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

תרגם את השמות של AWS למונחים של strongSwan

AWS מתארת את החיבור מצד הלקוח: כתובת שער הלקוח וה-CIDR המקומי שייכים לך, וה-CIDR המרוחק שייך ל-VPC. strongSwan מכנה את שני הקצוות left ו-right, כשהקידומת שלך ב-leftsubnet וקידומת ה-VPC ב-rightsubnet. היפוך של זוג אחד יוצר מנהרה שמנהלת משא ומתן ובוחרת את התעבורה הלא נכונה.

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

חוסר התאמה כאן נראה כמו כשל ניתוב וזה לא כך.

קבע את הכתובת ש-AWS באמת רואה

נתב מאחורי NAT יכול לשלוח IKE מממשק שהצד השני מעולם לא הכיר. כתובת השער שנרשמת ב-AWS חייבת להיות זו ש-AWS רואה על הרשת, והנתב חייב להיות מקובע לאותה כתובת מקומית במקום ללכת אחרי נתיב ברירת המחדל שלו.

conn %default
    local_addrs = 203.0.113.10

ב-strongSwan local_addrs בוחר את כתובת המקור עבור IKE, ותצורות OpenSwan ישנות יותר כותבות את אותו רעיון כ-left. כוון אותו לממשק שנושא את הכתובת הציבורית, ואז אמת על התקן ה-NAT עצמו ש-UDP 500 ו-4500 מגיעים לאותו מארח, כי כלל שנותר מנתב קודם מפיל אותם בשקט. זוג בוררים נכון עם כתובת מקור שגויה עדיין נכשל, והיומן יאשים את ההצעה. ההטעיה הזו היא הסיבה שכתובת המקור ראויה לבדיקה משל עצמה.

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

טפל בשלב 1 ובשלב 2 בנפרד

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

conn aws
    ike = aes256-sha1-modp1024
    esp = aes256gcm16

תחביר אינו עובר בין מימושים. זוג שעובד ב-OpenSwan, למשל phase2alg=aes_gcm עם ike=aes256-sha1;modp1024, זקוק לתרגום לצורה esp= ו-ike= של strongSwan, ושמות האלגוריתמים שונים. מכיוון ש-GCM מאמת תוך כדי הצפנה, הוא אינו זקוק לטרנספורמציית שלמות נפרדת, שלא כמו חבילת CBC שמשודכת ל-SHA. שורת שלב 2 שהודבקה מדמון אחד לאחר ללא תרגום מייצרת דחייה שנקראת כמו אי-התאמה של בוררים.

בדוק את אסוציאציית הבן, לא את מחוון המנהרה

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

ipsec statusall

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

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

כאשר זה עדיין נכשל לאחר שהבוררים תואמים

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

רשום חבילה נכנסת אחת ואחת יוצאת בכל צד לפני שתשנה הצעה נוספת.

רשום את הבוררים, את הצעות שלב 1 ושלב 2 ואת כתובת המקור בכרטיס. ארבעת הערכים האלה מסבירים את רוב כשלי site-to-site בלי שיחה.

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