ה-CIDR של לקוח AWS Client VPN אינו יכול לחפוף לטווח ה-VPC

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

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

חפיפה היא בדיקת טווחים, לא בדיקת כתובות פנויות

התחילו מה-CIDR של ה-VPC, לא מתת-הרשת שאתם מתכננים לשייך. מאגר של 172.20.0.0/22 יושב בתוך VPC של 172.20.0.0/16 ונפסל גם כשאין תת-רשת שתופסת אותו, כי חפיפה היא תכונה של הטווחים ולא של ההקצאות הנוכחיות. לאחר מכן הוסיפו את היעדים שאליהם נקודת הקצה מנתבת: VPCים עמיתים, שער מעבר וטווחים מקומיים דרך חיבור site-to-site. כל טווח שלקוח עשוי להזדקק להגיע אליו שייך לרשימה.

אספו אותם מהחשבון ולא מהזיכרון: aws ec2 describe-vpcs --query "Vpcs[].CidrBlock", בתוספת רשומות טבלת הניתוב של תת-הרשת שאתם מתכוונים לשייך.

גודל המאגר נקבע לפני הבנייה

AWS מקבלת מאגר לקוחות IPv4 בין /22 ל-/12 ב-Client VPN. ‏/24 קטן מדי, ‏/8 מחוץ לטווח המתועד, ושתי הטעויות נובעות ממדידת המאגר כמו תת-רשת של עומס עבודה. מדדו אותו לפי לקוחות מקבילים צפויים בתוספת מרווח, ואז עגלו לקידומת מותרת.

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

python3 -c "import ipaddress; p=ipaddress.ip_network('172.16.0.0/22'); print(p.num_addresses, p.prefixlen, p.overlaps(ipaddress.ip_network('172.20.0.0/16')))"

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

לפותר יש תפקיד כתובת משלו

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

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

ארבעה שדות שאתם מתחייבים להם ביצירה

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

בדקו את נקודת הקצה שנפרסה לפני שאתם מניחים שיש לבנות מחדש. aws ec2 describe-client-vpn-endpoints מחזיר את המאגר, ה-DNS, דגל ה-split-tunnel והשיוכים בתשובה אחת, ובדרך כלל זה מספיק כדי לשלול בנייה מחדש.

החליפו את נקודת הקצה במקום לתקן אותה

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

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

גבול אחד שראוי לציין: זה מכסה את מאגר הלקוחות של IPv4. הגדרות תעבורת dual-stack ו-IPv6 ב-Client VPN הולכות לפי מודל הכתובות שלהן, לכן אל תעתיקו את הרשימה הזו בלי לקרוא את התיעוד של אותו מצב.