AWS Client VPN מחובר, אבל EC2 עדיין לא מגיב
מחובר אומר רק שהתעודה או הכניסה ב-SAML עבדו. כללי הרשאה, מסלולי endpoint וקבוצות אבטחה כל אחד מהם שומר על חלק אחר בדרך אל מארח פרטי.
המחשב הנייד שלי הראה מחובר. לקוח AWS Client VPN הציג את מצבו הירוק, ה-endpoint רשם הפעלה, ובכל זאת לא הצלחתי לפתוח פורט MongoDB במופע EC2 בתת-רשת פרטית. שום דבר לא היה שבור לכאורה: התעודה הייתה תקפה, הפרופיל הגיע מהקונסולה והמנהרה העבירה תעבורה. הטעות הייתה שלי, כי קראתי מחובר כאל מורשה.
הכניסה עונה בדיוק על שאלה אחת: האם הזהות הזו רשאית להקים הפעלה? כל מה שאחרי זה נקבע על ידי כללים נפרדים שלעולם לא רואים את התעודה שלך. הפעלה שמבצעת אימות וחבילה שמגיעה הם שני הצלחות שונים, והפער ביניהם הוא המקום שבו גרות רוב התלונות מסוג ה-VPN פועל אבל המארח אינו נגיש.
הבדיקות שלמטה הן הסדר שבו אני משתמש עכשיו.
מה הפעלה מחוברת באמת מוכיחה
במהלך ה-handshake ה-endpoint מאמת את תעודת הלקוח מול מאגר האמון שלו, או מפנה את הדפדפן לספק הזהויות שלך כאשר SAML מוגדר. אם זה עובר, הלקוח מקבל כתובת מתוך ה-CIDR של הלקוח ב-endpoint והקונסולה מציגה חיבור פעיל. באף שלב של החליפין הזה שום דבר לא שואל אם אתה רשאי להגיע אל 10.0.4.17 בפורט 27017.
הרשאה ליעד היא אובייקט נפרד ב-endpoint. כל זרימה מושווית לכללי ההרשאה, וכל כלל מצמיד CIDR של יעד לקבוצה שהכלל ניתן לה. כאשר אין כלל שמכסה את היעד, ה-endpoint מקבל את ההפעלה וזורק את התעבורה. אין באנר, אין לולאת התחברות מחדש, ואין דבר בממשק הלקוח שאומר נדחה.
השוו את כלל ההרשאה למשאב, לא ל-VPC
הציגו את הכללים והניחו אותם לצד הכתובת שיש למופע בפועל:
aws ec2 describe-client-vpn-authorization-rules \
--client-vpn-endpoint-id cvpn-endpoint-0a1b2c3d4e5f6a7b8הפלט מציג CIDR של יעד ומזהה קבוצה לכל כלל. שני כשלים מסתתרים בו. הכלל עשוי להרשות 10.0.0.0/16 בשעה שהמופע יושב ב-VPC מקושרת ב-10.1.0.0/16; מסלול ה-peering קיים, אבל איש לא כתב כלל הרשאה לטווח השני. או שהכלל מצביע על קבוצת ספרייה שהמשתמש חבר בה בספרייה אך לא בקבוצה שה-endpoint מעריך.
כתבו את הכלל הצר ביותר שמכסה את היעד, והוסיפו כלל שני רק כאשר באמת נדרש CIDR נוסף. כלל רחב 0.0.0.0/0 מהתחלה מהירה עובד, ולכן הוא שורד לפרודקשן ומסתיר את המודל.
שני טבלאות מסלול מחליטות אם החבילה נעה
מסלול endpoint ממפה CIDR של יעד לאחת מתת-הרשתות שה-endpoint משויך אליהן. זה חצי דרך. טבלת המסלולים של תת-הרשת עצמה עדיין צריכה לדעת כיצד להעביר את החבילה הלאה, וזה חשוב ברגע שהיעד נמצא מאחורי חיבור peering, transit gateway או טווח מקומי שנגיש דרך מנהרת site-to-site.
aws ec2 describe-client-vpn-routes \
--client-vpn-endpoint-id cvpn-endpoint-0a1b2c3d4e5f6a7b8חפשו מסלול שהיעד שלו תואם ל-CIDR של המשאב והיעד שלו הוא תת-רשת משויכת. אם המסלול חסר, הוסיפו אותו. אם הוא קיים והמארח עדיין שותק, הפער בצד ה-VPC, אז השוו לטבלת המסלולים של תת-הרשת המשויכת.
הגדרה אחת בצד הלקוח שוברת את הניתוב בלי לשבור את המנהרה: פרופיל שמכיל route-nopull. ההנחיה אומרת ללקוח מבוסס OpenVPN להתעלם מהמסלולים שהשרת דוחף, כך שהממשק עולה רק עם הכתובת של ה-endpoint עצמו והיעד פשוט חסר מסלול. בדקו עם ip route show בלינוקס או netstat -rn ב-macOS אם קיים מסלול דרך ממשק ה-tun. אם לא, הסירו את route-nopull מהפרופיל המיוצא והתחברו מחדש כדי שהמסלולים הנדחפים יוחלו.
קבוצות אבטחה לא רואות את כתובת הלקוח שלך
זה החלק שבו טעיתי במשך אחר צהריים שלם. עבור endpoint של IPv4 המשויך לתת-רשת, השירות מתרגם את כתובת המקור של הלקוח לכתובת ממשק הרשת של ה-endpoint באותה תת-רשת. החבילה שמגיעה למופע אינה נושאת את הכתובת שהלקוח שלך הציג, ולכן כלל בקבוצת אבטחה שמתיר את מאגר הלקוחות, נניח 172.16.0.0/22, לא תואם דבר.
התירו את הפורט מקבוצת האבטחה של ה-endpoint, שמחוברת לממשק השיוך, ולא מה-CIDR של הלקוח. הפניה לקבוצה עמידה יותר מקידוד כתובת קשיח, כי כתובת הממשק אינה שלך לשליטה. רשימות ACL ברשת חסרות מצב, ולכן במקומות שיש בהם רשומות מותאמות, גם הכיוון הנכנס וגם הכיוון היוצא חייבים להתיר את הזרימה.
התחברו גם לכתובת הפרטית של המופע. IP ציבורי מוציא את החבילה מה-VPC ומחזיר אותה פנימה במסלול אחר עם כללים אחרים, ולכן בדיקה דרך הכתובת הציבורית לא אומרת דבר על המסלול הפרטי.
סדר בידוד שעוצר בכשל הראשון
עברו על אלה לפי הסדר ועצרו היכן שאחד נכשל. כל שלב שולל שכבה אחת ולא את כולן.
- אשרו באיזו זהות השתמשה ההפעלה ואיזו קבוצה ה-endpoint מעריך. תעודה ממאגר אמון אחד אינה אותו גורם כמו טענת SAML מהספרייה.
- אשרו שכלל הרשאה מכסה את ה-CIDR של המשאב עבור אותה קבוצה.
- אשרו שקיים מסלול endpoint שמכוון לתת-רשת משויכת, ואז שטבלת המסלולים של תת-הרשת יכולה להעביר הלאה.
- אשרו שקבוצת האבטחה מתירה את הפורט מממשק ה-endpoint ולא ממאגר הלקוחות.
- בדקו מתוך ה-VPC, עם הפעלת SSM במופע אחר באותה תת-רשת, כדי להפריד בעיית יישום מבעיית מסלול לקוח.
כשהשלבים אינם מכריעים, הטבלה הזו היא מה שאני נשען עליו:
| Symptom | Layer to inspect |
|---|---|
| Client shows connected, host times out, no byte growth on the interface | Authorization rule, then security group |
| Ping fails but a TCP connect to the port succeeds | ICMP is blocked; not an access failure |
| Tunnel reconnects every few minutes | Two machines sharing one client certificate |
| Works on one laptop, fails on another | Local profile has route-nopull or stale pushed routes |
שני פרטי חשבון מייצרים תסמינים שנראים כמו כשל הרשאות. כל משתמש זקוק לתעודת לקוח נפרדת; שיתוף תעודה אחת בין שתי מכונות גורם להפעלות לדחוק זו את זו, והתוצאה היא לולאת התחברות מחדש ולא דחייה. כאשר נוצר endpoint חדש, הקונסולה מציגה שם DNS שחלק מגרסאות הלקוח מקבלות רק עם הקידומת האקראית שמוצגת בעמוד ה-endpoint, ולכן העתיקו את השם המלא במקום לשחזר אותו.
אם השלב החמישי משאיר אתכם תקועים, משכו את יומן החיבורים של ה-endpoint וקראו את רשומות ההרשאה לפני שמשנים משהו. היומן מציין את היעד שנבדק ואת הכלל שהתאים או לא התאים, וזה ממצה את השאלה בעלת ארבע השכבות לתשובה אחת.