VGW או TGW? היכן מסתיים מנהרת ה-IPsec של AWS Site-to-Site

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

תנו שמות לשלושת הקצוות לפני שאתם מעריכים משהו

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

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

בדיקה 1: איזה שער באמת מסיים את המנהרה

שני הסידורים נתמכים ו מדריך הארכיטקטורה של Site-to-Site VPN מתאר אותם זה לצד זה, אז שאלו את ה-API ולא תרשים שלעתים קרובות בן שנה. שאילתת קריאה בלבד על חיבור אחד מחזירה את שדות יעד ה-VPN:

aws ec2 describe-vpn-connections --region eu-west-1   --vpn-connection-ids vpn-0123456789abcdef0   --query 'VpnConnections[0].{VGW:VpnGatewayId,TGW:TransitGatewayId,CGW:CustomerGatewayId,Category:Category}'

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

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

aws ec2 describe-vpn-tunnels --region eu-west-1   --filters Name=vpn-connection-id,Values=vpn-0123456789abcdef0   --query 'VpnTunnels[].{Outside:OutsideIpAddress,State:State,Status:Status}'

בדיקה 2: מה החבילה הפנימית עדיין נושאת

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

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

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

בדיקה 3: מה מסיים TLS מאחורי השער

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

בדקו את הקצה שבאמת חשוב לכם מתוך ה-VPC, עם השם שהאפליקציה משתמשת בו ולא עם IP שפתרתם פעם אחת:

openssl s_client -connect internal.example:443 -servername internal.example -verify_return_error

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

רשמו את התוצאה כמקטעים, לא כפסק דין

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

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

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