גישה לסירוגין ב-AWS Client VPN: בדקו כל תת-רשת משויכת
חלק מהפעלות AWS Client VPN מגיעות ל-VPC של האפליקציה ואחרות נגמרות בזמן. השוו תחילה את המסלולים של נקודת הקצה עם טבלת המסלולים של ה-VPC בכל שיוך.
משתמש מתחבר, פותח את האפליקציה הפנימית ומקבל תשובה; עמית באותה נקודת קצה מקבל פסק זמן ממחשב נייד זהה באותה רשת Wi-Fi. התבנית הזו היא החתימה של נקודת קצה של client VPN עם יותר מתת-רשת משויכת אחת, שבה הנתיבים אינם שקולים. אני עובר על זה מהקונסולה החוצה, כי שתי לשוניות קובעות אם שאר החקירה שווה את המאמץ. שום דבר בהגדרות הלקוח לא מסביר את זה.
התחילו בנקודת הקצה ורשמו את השיוכים
בקונסולת VPC פתחו Client VPN endpoints, בחרו את נקודת הקצה וקראו את הלשונית Associations. כל שיוך הוא תת-רשת באזור זמינות, והלקוח נוחת על זו שהשירות בוחר כשהחיבור נבנה. רשמו את מזהי תת-הרשתות ואת טבלת המסלולים שכל אחת באמת משתמשת בה, כי שתי הרשימות האלה הן ההשוואה שאתם עומדים לעשות.
אם נקודת הקצה מציגה שיוך אחד בלבד, התיאוריה הזו שגויה והלקוח הוא החשוד הטוב יותר.
השוו את טבלת המסלולים של נקודת הקצה לכל שיוך
פתחו את הלשונית Route table באותה נקודת קצה. לכל CIDR יעד שם יש מטרה, וב-client VPN המטרה היא שיוך ולא שער. AWS דורשת רשומת יעד לכל תת-רשת משויכת, ולכן מסלול שמכוון רק לאחת מהן הופך את הגישה לתלויה במקום שבו נחתה ההפעלה. בדקו את היעד שבאמת חשוב לכם, ואז את כלל ההרשאה שלו, כי מסלול מספק את הנתיב וכלל קובע מי רשאי להשתמש בו.
ברגע שתעלו את שתי השכבות לטבלה, קשה לפספס את התקלה.
| Associated subnet | Endpoint route to 10.200.0.0/16 | VPC route in that subnet |
|---|---|---|
| subnet-aaa | Targets the association | 10.200.0.0/16 to pcx-example |
| subnet-bbb | Targets the association | No matching entry |
השורה השנייה היא כל הבאג ברוב הפניות. מסלול נקודת הקצה קיים, ולכן אף אחד לא מסתכל הלאה, והחבילה מתה קפיצה אחת אחר כך בתוך ה-VPC.
עקבו אחרי כל תת-רשת אל טבלת המסלולים האפקטיבית שלה
תת-רשת בלי שיוך מפורש לטבלת מסלולים יורשת את הטבלה הראשית של ה-VPC. קראו את הטבלה שבאמת בתוקף, לא זו ששמה נראה נכון, והשוו יעד ומטרה במקום את התווית בשורה.
המדריך של AWS לגישה לסירוגין מתאר זאת ככיסוי מסלולים על פני השיוכים, וזה המודל הנכון. נקודת הקצה מביאה את החבילה לתת-רשת, והטבלה של אותה תת-רשת עדיין חייבת לדעת איפה נמצאת רשת האפליקציה.
תקנו את השורה החסרה בטבלה שבבעלותה. העתקת טבלת מסלולים שלמה מתת-רשת שעובדת מעתיקה גם בחירות אינטרנט, התקן ובידוד שלא נועדו מעולם לזו, וההחלפה הזו בדרך כלל גרועה מהתקלה שאיתה התחלתם.
בדקו את כללי ההרשאה, ואז את נתיב החזרה
כללי הרשאה הם לפי יעד ולפי קבוצה, והם נבחנים בנפרד מהמסלולים. יעד עם מסלולים בכל מקום אבל בלי כלל לקבוצה של המשתמש מתנהג כמו חור שחור עם טבלת מסלולים שנראית בריאה.
נתיב החזרה ראוי לאותה תשומת לב. חיבור peering צריך מסלול ב-VPC של האפליקציה שמצביע חזרה ל-CIDR של הלקוח, כללי קבוצת אבטחה שמאפשרים את התעבורה בשני הקצוות, ו-ACL של רשת שלא מפילים אותו. נגישות חד-כיוונית, שבה ping עובד ולחיצת היד של TCP לא, מצביעה בדרך כלל על ACL או קבוצת אבטחה ולא על ה-VPN.
קבוצות האבטחה של נקודת הקצה עצמה יושבות על ממשקי הרשת האלסטיים של השיוך, ולכן כלל שמאפשר את פורט האפליקציה מ-CIDR של הלקוח חייב להיות מחובר לשיוך, לא רק למופע.
אמתו בחיבור מחדש, לא בבקשה אחת ברת מזל
עם split tunnel, מסלולי נקודת הקצה נדחפים כשהחיבור נוצר, ולכן סט מסלולים שהשתנה לא מגיע לעולם ללקוח שנשאר מחובר. נתקו והתחברו מחדש דרך הלקוח הנתמך, ואז ודאו שהמסלולים החדשים קיימים במכונה.
לבסוף, התאימו את יומן החיבורים לכתובת שהלקוח קיבל, וחזרו על הבדיקה מספיק פעמים כדי לפגוע ביותר משיוך אחד. בקשה מוצלחת אחת אחרי תיקון מוכיחה שנתיב אחד עובד, והפנייה הייתה על האחר.