איזו כתובת IP מקור משמשת שער NAT של AWS כלפי VPN?

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

התחילו בדף שערי NAT, לא ברשימת ההיתרים

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

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

עקבו אחר שתי ההמרות

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

workload 10.20.1.5 -> NAT gateway 10.20.2.10 -> internet gateway -> Elastic IP 203.0.113.25
workload 10.20.1.5 -> NAT gateway 10.20.2.10 -> transit or virtual private gateway -> partner sees 10.20.2.10

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

מסלול ה-VPN מציג בדרך כלל את הכתובת הפרטית

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

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

כאשר המרה שנייה משנה את התשובה

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

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

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

כתבו את החוזה שהשותף שלכם יכול לפעול לפיו

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

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

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