כתובת Elastic IP של EC2 אינה כתובת ה-VPN הפרטית של המופע
האורח לעולם אינו רואה את ה-Elastic IP. עקבו אחר היכן מתרחשת התרגום, ואז בחרו את הכתובת ששייכת למסלול שאתם באמת צריכים.
למופע יש כתובת פרטית, ה-Elastic IP משויך אליה, ומסלול עבור אותו /32 ציבורי מתווסף ל-VPN בתקווה ששני הדברים יהפכו לאותו דבר. הם לא. Elastic IP הוא תרגום שמבוצע מחוץ לאורח, על ידי שער האינטרנט, על תעבורה שהולכת במסלול האינטרנט. מערכת ההפעלה של האורח לעולם אינה רואה את הכתובת הזו מוגדרת על ממשק. הוספתה לממשק מנהרה אינה משחזרת את התרגום במעלה הזרם והיא יוצרת זהות שנייה וסותרת לאותה מכונה.
שתי כתובות, מופע אחד
ממשק הרשת של המופע מחזיק כתובת פרטית בתוך ה-VPC, וזו הכתובת שהאורח מכיר. ה-Elastic IP משויך לאותו ממשק אך חי בצד הציבורי של המיפוי.
כל דבר שמגיע למופע דרך האינטרנט מגיע מתורגם לכתובת הפרטית. כל דבר שהמופע שולח לאינטרנט יוצא עם ה-Elastic IP כמקור, שוב בגלל אותו תרגום.
בתוך האורח קיימת כתובת אחת. בחוץ קיימות שתיים. חוסר הסימטריה הזה מסביר את רוב הבלבול בתחום הזה. האורח אינו יכול להגדיר מה השער מתרגם. הוא יכול לענות רק על הכתובת שהוא באמת מחזיק.
מה שער האינטרנט באמת עושה
התיעוד של AWS על שער האינטרנט מתאר את הסידור: המופע מודע לכתובת ה-IPv4 הפרטית שלו, והשער מספק את התרגום המתאים ל-IPv4 ציבורי או ל-Elastic IP עבור תעבורה במסלול האינטרנט.
זהו תרגום כתובות רשת, לא כינוי. המיפוי מתוחזק על ידי השער, קשור לשיוך, וחל רק על מנות שעוברות דרכו. הסירו את השיוך והזהות הציבורית נעלמת בלי שהאורח יבחין בדבר.
לכן מנת VPN פרטית הממוענת ל-/32 הציבורי אינה מתפרשת מחדש כמנה פרטית לכתובת המקומית של האורח. המנה עוקבת אחר המסלול שאליו היא מתאימה, וזה שולח אותה לשער האינטרנט, והתנהגות השער תלויה בכך שהמסלול מותר בשני הכיוונים.
למה הטריק של ממשק המנהרה נכשל
הקצאת ה-Elastic IP לממשק מנהרה מבקשת מהאורח להתייחס לכתובת ציבורית כאל מקומית. כעת שני דברים תובעים את אותה כתובת: התרגום של השער במסלול האינטרנט והממשק המקומי בתוך המנהרה. לתעבורת החזרה אין תשובה עקבית איזו מהן חלה.
גם כשזה נראה עובד, התכנון הסתיר את השאלה האמיתית. לקוחות מגיעים לכתובת הפרטית דרך המנהרה או לנקודת הקצה הציבורית דרך האינטרנט, ולשני המסלולים יש קבוצות אבטחה שונות, תיעוד שונה ואופני כשל שונים.
הכתובת מעולם לא הייתה הבעיה. בחירת המסלול הייתה.
שלושה יעדים, שלושה תכנונים
אם היעד הוא נקודת קצה ציבורית של VPN, ה-Elastic IP הוא הכלי הנכון: עמיתים מרוחקים מתחברים אליו דרך האינטרנט והתעבורה המוצפנת מסתיימת במופע. לאחר מכן תעבורת היישום הפנימית משתמשת בכתובת הפרטית.
אם היעד הוא גישה פרטית ליישום, היעד הוא הכתובת הפרטית או שם DNS פרטי שמתרגם אליה, ומסלול ה-VPN, קבוצת האבטחה ומסלול החזרה חייבים כולם להסכים. ה-Elastic IP אינו מופיע בתכנון הזה כלל.
אם היעד הוא זהות יציאה ציבורית יציבה למשתמשי VPN, זהו תכנון NAT בצד היציאה, לא כתובת במנהרה של הלקוח. שלושה יעדים שנשמעים דומה מייצרים שלושה תרשימים שונים, ורק אחד מהם כולל הצבת Elastic IP במקום חדש.
אמתו את המסלול שבחרתם
לגישה פרטית, ודאו שמסלול ה-VPN מכסה את הקידומת הפרטית, שטבלת המסלולים של ה-VPC מחזירה תעבורה למנהרה, שקבוצת האבטחה מתירה את מקור הלקוח ושחומת האש של הלקוח עצמו מתירה את התשובה. לאחר מכן בדקו בקשה אמיתית אחת במקום ping.
לגישה ציבורית, ודאו את יציאת האינטרנט של הלקוח, את הניתוב של הכניסה הציבורית ואת מדיניות האבטחה שלה. האם לקוח VPN יכול להגיע לנקודת קצה ציבורית דרך המנהרה תלוי בכללי היציאה ובחומת האש של המנהרה, לא בשיוך ה-Elastic IP.
אם שם מארח ציבורי חייב לעבוד משני הצדדים, השתמשו בתכנון DNS שמשיב בכתובת הפרטית ללקוחות VPN ובכתובת הציבורית לכל השאר, ושמרו על התעודה תקפה עבור השם ולא עבור הכתובת. סדר העבודה: תנו שם ליעד, בחרו את הכתובת ששייכת לו, ואז אמתו מסלולים, מדיניות ובקשה אחת.