למה ייבוא מחדש של תעודת Client VPN דורש נקודת קצה חדשה

חיבור Client VPN נשבר, התעודה ב-ACM מוחלפת, ושום דבר לא משתנה. אובייקט התעודה מעולם לא היה הדבר שנקודת הקצה השתמשה בו. נקודת קצה שומרת בעת היצירה קישור לתעודה, יחד עם ה-CA של הלקוח שמולו היא תאמת, סוג האימות, תת-הרשתות וכללי ההרשאה, ולאף אחד מהקשרים האלה אין קריאת שינוי שמקבלת תעודת החלפה. החלפת הבייטים שמאחורי ARN היא שינוי בתעודה, לא בנקודת הקצה שלכדה אותה.

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

כדאי לנסח את המנגנון במדויק, כי הוא מסביר את כל הכשל. create-client-vpn-endpoint מקבל ARN של תעודת שרת ו-ARN של שרשרת תעודות שורש של לקוח, ונקודת הקצה שנוצרת שומרת את ההפניות האלה יחד עם אפשרויות האימות כמאפיינים קבועים. ממשק ה-API אינו מציע פעולה שמחליפה את תעודת השרת בנקודת קצה קיימת.

אפשר לאמת את הקישור בלי לנחש. aws ec2 describe-client-vpn-endpoints --client-vpn-endpoint-ids cvpn-endpoint-0123456789abcdef0 מדפיס את ה-ARN של התעודה, את ה-ARN של שרשרת השורש של הלקוח, את סוג האימות, את ה-CIDR של הלקוח ואת תת-הרשתות המשויכות, שזו הקבוצה המלאה של מאפיינים שהייתם צריכים לשחזר. הריצו אותו לפני ואחרי ייבוא מחדש והפלט לא זז. זו ההוכחה שהייבוא מחדש מעולם לא היה אמור לעזור.

למה ייבוא מחדש לא יכול להגיע לנקודת הקצה

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

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

השרשרת היא חלק מתעודת הלקוח

המחצית השנייה של הכשל נמצאת בתעודת הלקוח, וקל יותר להתעלם ממנה. תעודת לקוח חייבת להיות מיובאת עם השרשרת שהנפיקה אותה, למרות שטופס הייבוא מציג את השדה הזה כאופציונלי. בלי השרשרת נקודת הקצה לא יכולה לבנות נתיב מתעודת הלקוח אל ה-CA השורש של הלקוח שאיתו היא הוגדרה, והחיבור מסתיים באיפוס רך שנשמע כמו חומת אש שמשליכה מנות. openssl verify -CAfile root-ca.pem client.crt עונה על השאלה הזו מקומית בשנייה, וזה צריך להיות הפקודה הראשונה שתריצו.

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

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

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

הסדר ששומר על זה בטוח הוא קצר: צרו את נקודת הקצה החדשה עם אותו CIDR, אותן תת-רשתות ואותם כללי הרשאה, ייצאו פרופיל חדש עם aws ec2 export-client-vpn-client-configuration, ואמתו עם משתמש אחד. רק אחרי זה נקודת הקצה הישנה יורדת.

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

סדרו את האבחון

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

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

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