CIDR מקומי ומרוחק ב-AWS VPN: איזה צד הוא איזה?

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

התחילו מקריאת ה-API, לא מתווית המסוף

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

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

דוגמה מלאה עם התפקידים

נניח שהקידומת המקומית היא 10.20.0.0/16 וקידומת ה-VPC היא 10.60.0.0/16. האפשרויות נקראות בדיוק כפי שהתפקידים מרמזים, כשטווח המקומי נמצא בשדה המקומי:

{
  "LocalIpv4NetworkCidr": "10.20.0.0/16",
  "RemoteIpv4NetworkCidr": "10.60.0.0/16"
}

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

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

ברירות מחדל אינן תכנון

אותו מדריך מפרט 0.0.0.0/0 כברירת מחדל לשני שדות IPv4, עם ערכים דומים עבור IPv6. לראות את הערכים האלה בחיבור קיים אומר שהשדה מעולם לא צומצם, ולא שהוגדרה יציאה לאינטרנט. הפצת מסלולים, טבלת המסלולים של תת-הרשת ובקרות האבטחה עדיין קובעות איזה תעבורה באמת יכולה לעבור; ערכי CIDR רק מתארים אילו טווחים המנהרה מוכנה לבחור.

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

התקן העמית משתמש בנקודת המבט האחרת

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

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

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

שנו את האפשרויות כשינוי, לא כתיעוד

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

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

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