AWS Site-to-Site VPN אל NAT Gateway: VGW לעומת Transit Gateway

כולם מציירים את אותה תרשים בפעם הראשונה: VPN אל ה-VPC, NAT gateway אל האינטרנט, סוף. אבל AWS אינה תומכת במסלול הזה כשהחיבור מסתיים ב-virtual private gateway, והכשל שקט כל כך שצוותים בונים אותו מחדש יותר מפעם אחת. העיצוב שעובד דורש transit gateway, וזה משנה את השער ואת טבלאות הניתוב בשני הצדדים. השוו בין שתי הצורות לפני שמציירים משהו.

הטופולוגיה שנראית מובנת מאליה ואינה נתמכת

התיעוד של NAT gateway ב-AWS משרטט קו שמפתיע כל מי שבנה רק עיצובי VPC יחיד: לא ניתן לנתב תעבורה מחיבור Site-to-Site VPN אל NAT gateway דרך virtual private gateway. סוג השער שעליו מסתיים ה-VPN קובע אם קיים בכלל מסלול תרגום. הטעות שורדת משום שמצב המנהרה הוא UP ומופע EC2 באותו subnet מגיע לאינטרנט בלי בעיה. אף אחת משתי התצפיות לא בודקת את הכיוון השבור.

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

virtual private gateway לעומת transit gateway

virtual private gateway שייכת ל-VPC אחד. היא מסיימת את ה-VPN, מתקינה נתיבים בטבלאות של אותו VPC ועוצרת שם. אין לה מודל attachment, ולכן היא אינה יכולה להעביר תעבורה ל-VPC אחר או למקטע יציאה משותף. כל המגבלה היא ההיקף של VPC יחיד, ואף נתיב שתוסיפו בתוך ה-VPC לא משנה אותה.

transit gateway הוא רכז אזורי שבו ה-VPN, כל spoke VPC ו-VPC של שירותים משותפים מופיעים כ-attachments. יש לו טבלאות ניתוב משלו, שבוחרות איזה attachment יקבל prefix נתון.

הרכז הזה הוא מה שמאפשר יציאה מרוכזת: ה-VPN נוחת כ-attachment אחד, VPC היציאה כאחר, וטבלת ניתוב של transit gateway שולחת prefixes לכיוון האינטרנט מהראשון לשני. עם virtual private gateway אין attachment שני לשלוח אליו דבר, ולכן אי אפשר לתקן את העיצוב בדיעבד.

מסלול היציאה הנתמך, צעד אחר צעד

לעיצוב הייחוס חמישה צעדים וכל חץ הוא החלטת ניתוב שעליכם להגדיר. התעבורה יוצאת מהרשת המקומית אל attachment של Site-to-Site VPN, טבלת ה-transit gateway מעבירה אותה אל attachment של VPC היציאה, ושם טבלת ה-subnet שולחת אותה אל NAT gateway ציבורי. ה-NAT gateway מתרגם את המקור וה-internet gateway מוציא את החבילה.

On-premises network
  -> Site-to-Site VPN attachment on the transit gateway
  -> transit gateway route table
  -> egress VPC attachment
  -> public NAT gateway in that VPC
  -> internet gateway

שני פרטים קובעים אם הצעדים האחרונים יעבדו. ה-NAT gateway חייב להיות ציבורי, עם elastic IP ונתיב אל internet gateway, כי NAT gateway פרטי מתרגם בין רשתות ולעולם אינו הופך ליציאת אינטרנט.

תכננו NAT gateway אחד לכל Availability Zone שתרצו לשרת, כשכל טבלת subnet מצביעה על המקומי. החזיקו את טבלת ה-transit gateway ואת טבלאות ה-VPC כעצמים נפרדים בהערותיכם, כי האחת בוחרת attachment והאחרת בוחרת משאב בתוך ה-VPC. נתיב ברירת מחדל באחד מהם בלבד משאיר חצי מהמסלול לא מוגדר ומייצר את הכשלים החלקיים שהכי קשה לאבחן.

מסלול החזרה הוא המקום שבו העיצובים האלה נכשלים

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

אמתו עם לקוח אמיתי מאחורי ה-VPN ובדקו איזו כתובת מקור ציבורית הוא מציג. אם זו ה-elastic IP של ה-NAT gateway, מתרחש תרגום; אם זה משהו אחר, אתם מודדים יציאה אחרת.

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

מתי proxy מפורש הוא העיצוב העדיף

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

אבל הוא אינו שקוף. כל מה שמתעלם מהגדרות ה-proxy, וכל פרוטוקול שאינו HTTP, לא ילכו במסלול הזה.

הבחירה תלויה במה שהיישומים שלכם באמת מדברים וכמה זהות אתם צריכים ברישומים. במקום שהם מדברים HTTP, ה-proxy זוכה במקומו; במקום שצריך יציאה כללית לפרוטוקולים שרירותיים, עיצוב ה-transit gateway הוא זה ש-AWS תומכת בו. להחליט על כך מראש זול יותר מלגלות אותו אחרי בניית טבלאות הניתוב.