למה EC2 לא יכול להגיע למחשב הנייד שלך ב-AWS Client VPN
Client VPN מתרגם מקורות IPv4 של הלקוח לממשק נקודת הקצה. לכן התשובה עובדת וחיבור חדש מ-EC2 לא.
מחשב נייד המחובר דרך AWS Client VPN מגיע ליישום ב-EC2 בלי שום בעיה. אחר כך מנסים את הכיוון ההפוך, מ-EC2 לכתובת שהוקצתה ללקוח, והחיבור נתקע או נדחה. חוסר הסימטריה הזה נובע רק לעיתים נדירות מכלל קבוצת אבטחה חסר. בנקודת קצה של Client VPN שמשויכת לתת-רשתות של VPC, AWS מתרגם מקורות IPv4 של הלקוח לממשק הרשת של נקודת הקצה, ולכן אין כתובת VPC נכנסת שמייצגת את המחשב הנייד שלך.
מתחילים ממה שהלכידה מראה
בצעו לכידה במארח ה-EC2 בזמן שהלקוח מתחבר, וקראו את כתובת המקור שהיישום באמת רואה. אם זה ממשק נקודת הקצה בצד ה-VPC ולא כתובת ממאגר הלקוחות, התרגום מאומת לפני ששיניתם אפילו כלל אחד.
מאגר הלקוחות הוא טווח הקצאה, לא תת-רשת עם נתיב חזרה. בנקודה הזו רוב החקירות מהסוג הזה טועות.
התרגום שמסביר את חוסר הסימטריה
שלושה זרמים מתבלבלים זה עם זה, ורק אחד מהם הוא זה שאנשים בודקים.
| Flow | Started by | What the VPC sees | Outcome |
|---|---|---|---|
| Client to EC2 service | The client | A translated source at the endpoint interface | Works, with a stateful reply |
| EC2 host to client pool address | The EC2 host | A destination with no route and no translation state | No usable path |
| Client to client | A client, when the feature is configured | Traffic mediated by the endpoint | Works only with that feature and its authorisation |
תיאור הרכיבים של Client VPN מפרט שמקורות IPv4 של הלקוח מתורגמים לממשק נקודת הקצה, וזה מספיק כדי לראות למה לשורה האמצעית אין עם מה להתאים.
חיבור חדש זקוק לנתיב, לשלב של פתרון כתובות ולהחלטת הרשאה. מצב התרגום מהפעלה של מישהו אחר לא מספק אף אחד מהשלושה.
למה תשובה אינה חיבור חדש
תשובת TCP מותאמת לרשומה קיימת, ולכן נתיב החזרה עובד בלי שום כלל נכנס. ל-SYN חדש מהמארח EC2 אין רשומה להתאים לה, ולכן הוא הופך לניסיון יוצא רגיל לעבר יעד שה-VPC לא יודע איך להגיע אליו.
זו גם הסיבה שהתיאור של זה כתעבורה בכיוון אחד בלבד מטעה. תעבורת החזרה זורמת ברציפות בהפעלות האלה. החלק בלי נתיב הוא היזימה.
מה עדיין שובר הפעלה שאמורה לעבוד
קבוצות אבטחה, רשימות ACL של הרשת וחומת האש של המחשב הנייד עצמו כולם חשובים לחיבורים שאמורים להצליח. ping שנכשל אומר הכי מעט, כי מדיניות ICMP לעיתים קרובות נפרדת ממדיניות ה-TCP שמעניינת אתכם.
כתבו את הכללים האלה לפי המקור המתורגם, לא לפי כתובת הלקוח. כללים שתלויים בכתובת שלעולם לא מופיעה ברשת הם הכשל העצמי הנפוץ ביותר בתכנון הזה.
כשה-VPC באמת חייב להתחיל את השיחה
אם שירות צריך להודיע לתחנת עבודה, הפיכו את הכיוון ותנו ללקוח להחזיק ערוץ יוצא מתמשך שהשירות עונה עליו. אם רשת מרוחקת שלמה צריכה להיות נגישה מה-VPC, בחרו בארכיטקטורה שמפרסמת את הקידומות ומדיניות הגישה שלה במקום להניח ש-Client VPN כבר עושה זאת. גישה מלקוח ללקוח היא מקרה שלישי וצר יותר, עם אובייקטי נתיב והרשאה משלו. אף אחד מאלה אינו תיבת סימון בנקודת הקצה הקיימת.
שמרו גם על היקף כן של הסבר ה-IPv4. התיעוד הנוכחי של AWS מפריד את IPv6, שבו התרגום הזה לא חל, ואת מודלי החיבור האחרים שמנתבים אחרת.
בדקו בשלושה שלבים מתויגים: הלקוח פותח הפעלה מורשית, שירות ה-VPC עונה לאותה הפעלה, ומארח ב-VPC פותח הפעלה חדשה לעבר הלקוח. ההצלחה של השניים הראשונים וכשל השלישי הם הצורה הצפויה של התכנון הזה, לא פגם שצריך לרדוף אחריו בכללי חומת אש.