DNS של נקודת הקצה ב-AWS Client VPN: מדוע נעיצת ה-IP שנפתר נכשלת
החליפו את שם נקודת הקצה של AWS Client VPN בכתובת שפתרתם, והמנהרה תפסיק לעבוד מאוחר יותר. שמרו על השם המיוצא ועל הקידומת האקראית שלו.
בשבוע שעבר dig +short נתן לכם כתובת אחת עבור שם נקודת הקצה בפרופיל AWS Client VPN שלכם, והמנהרה התחברה. השבוע אותו פרופיל עומד על 'Connecting' במחשב הנייד שלכם בעוד עותק לא נגוע של עמית עדיין עובד. דבר לא נחסם והתעודה לא פגה. מישהו החליף את שם המארח של נקודת הקצה בכתובת שנפתרה ההיא, והשירות כבר לא עונה שם. השם המיוצא הוא החלק שנבנה כדי לשרוד את השינוי הזה.
השם בפרופיל שלכם עשוי שלא להיות השם שנשאל
פרופילים המיוצאים מ-Client VPN נושאים לעתים קרובות remote-random-hostname. כשהאפשרות הזו פעילה, הלקוח בונה תווית חד-פעמית, מצרף אותה לשם נקודת הקצה בנקודה, ופותר את השם המשולב. רשומת wildcard באזור של נקודת הקצה עונה לכל תווית, ולכן קידומת מומצאת עדיין נפתרת, ולכן הטריק נשאר בלתי נראה כשאתם מנסים לשחזר את השאילתה ביד.
אז כשאתם מדביקים את שם נקודת הקצה במסוף ומקבלים תשובה, פתרתם שם אחר מזה שהלקוח משתמש בו בזמן ההתחברות. אי-ההתאמה הזו אינה פגם שיש לתקן בפרופיל. התווית נוצרת מחדש בכוונה: האפשרות מונעת ממטמונים להחזיק תשובה מיושנת, והיא לעולם אינה מזהה את המכונה או את ההפעלה שלכם.
נתקלתי במקרה התאימות שבו לקוח מתעלם מהאפשרות לחלוטין. AWS מתעד את העקיפה: שמרו על שם נקודת הקצה האמיתי והוסיפו לפניו מחרוזת אקראית ונקודה, והתייחסו לכך כתבנית שמות ולא כערך להדבקה. החלה של זה על לקוח ישן היא סבירה; קידוד נוקשה של המחרוזת עם הקידומת כנקודת קצה אינו כזה.
מדוע תשובה שמורה אינה יכולה להישאר נכונה
כתובות נקודת הקצה של Client VPN מנוהלות על ידי AWS ומשתנות עם הזמן, וכך אומרת תיעוד השיטות המומלצות במפורש. תשובה שנלכדה היא צילום של פתרון אחד. פרופיל שמקודד אותה נוקשה הופך לפרופיל שמכוון למארח שהוצא משימוש ברגע שהשירות עובר, והכשל כמעט אינו נראה כמו DNS: מקבלים פסק זמן בחיבור או לחיצת יד תקועה, ולכן אנשים רודפים אחרי ניתוב ותעודות.
אותה תשובה ב-/etc/hosts יורשת את אותה תפוגה עם בעיה נוספת. רשומת hosts שורדת הפעלות מחדש, ייצוא חוזר ותיקוני 'התקן מחדש את הלקוח', ולכן הכשל חוזר בכל פעם שהכתובת עוברת. ראיתי אחת יושבת בלי נזק במשך שבועות ואז מפילה כל מכונה שנשאה אותה בעוד התקנות חדשות התחברו כרגיל. הפיצול הזה, קבוצה אחת נכשלת ואחרת תקינה באותו חשבון, הוא הרמז הזול ביותר שתקבלו.
הגבילו נכון את היקף האקראיות. היא מתרחשת בכל ניסיון התחברות. מנהרה מבוססת אינה פותרת מחדש את נקודת הקצה שלה, אינה מחליפה שרתים באמצע ההפעלה, ובקשות יישום בודדות אינן בוחרות כל אחת מארח VPN חדש. רק הניסיון הבא פותר מחדש, ולכן הפעלה שעובדת כל אחר הצהריים אינה אומרת דבר על מחר בבוקר.
מה השירות בודק כשהמנהרה עולה
Client VPN דורש שהכתובת שאליה אתם מחוברים תתאים לכתובת שנפתרה עבור שם ה-DNS של נקודת הקצה. הדרישה האחת הזו מסבירה כמה כשלים שנראים לא קשורים: רשומת DNS מותאמת שמצביעה למקום אחר, frontend מותאם שמעביר לכתובת נקודת הקצה האמיתית, ופרופיל שנכתב מחדש לכתובת גולמית. AWS מתעד את הסידור של רשומה מותאמת בתוספת העברה ככשל עם לקוחות AWS עדכניים. הבדיקה צרה; היא אינה פסק דין שכל כינוי אסור.
זה גם לא כלל כללי לגבי פרוטוקולי VPN. remote מספרי תקף לחלוטין ב-פריסת OpenVPN רגילה, ורבים פועלים כך. המגבלה מגיעה מהסידור המנוהל, לא מהפרוטוקול שמתחתיו.
מה שהופך את הרפיית אימות התעודה לרפלקס הלא נכון. אם פרופיל נכשל לאחר החלפת כתובת, השבתת אימות השרת מעבירה את השגיאה במקום לתקן את הפתרון או את דרישת התאמת הכתובת, ומשאירה לקוח שיבטח בכל דבר. שמרו על ה-CA המיוצא, אימות השרת והגדרות האימות ההדדי בדיוק כפי שהגיעו.
רשימות היתר, יציאה ו-DNS פרטי הם שלוש בעיות נפרדות
כלל חומת אש שחייב להתיר יעד לפני שהמחשב הנייד מתחבר עוסק במאזין החיצוני. תנו לבעל הרשת את שם נקודת הקצה, את התעבורה ואת הפורט המוגדר, ואז שאלו אם הבקרה שלהם יכולה לעקוב אחר התנהגות ה-DNS של השירות. כלל שמחזיק כתובת אחת שנלכדה הוא צילום עם תפוגה לא כתובה. אם הבקרה מקבלת רק יעדים בלתי משתנים, סגרו את הפער הזה לפני ההפצה במקום לקודד תשובה בשקט.
לשותף שזקוק לכתובת מקור קבועה לבקשות שנעשות אחרי עליית המנהרה יש דרישה אחרת: יציאה. מה שאתר רואה תלוי במסלול היישום ובמדיניות המנהרה המפוצלת, לא בכתובת שאליה התחבר הלקוח. תעבורה במנהרה מפוצלת עשויה כלל לא לגעת ב-AWS.
DNS פרטי בתוך המנהרה הוא שכבה שלישית. הפותר שניתן ללקוחות עונה לשמות פנימיים לאחר ההתחברות; הוא אינו יכול לפתור את נקודת הקצה הציבורית לפני שהמנהרה קיימת. כשל בפתרון נקודת הקצה וכשל בפתרון יישום פנימי מתרחשים בשלבים שונים, וערבוב ביניהם שולח אתכם ליומן הלא נכון.
משפחת הכתובות שייכת לאותה רשימה. תשובת IPv4 אינה אומרת דבר על המסלול המותר של נקודת קצה IPv6 או כפולת מחסנית, ולכן צילום שנלקח במשפחה אחת אינו ראיה לאחרת.
בדקו חיבור בלי לנעוץ דבר
התחילו מהפרופיל כפי שיוצא וקראו מה הוא באמת מבקש:
grep -nE '^remote|remote-random-hostname' profile.ovpn
dig +short cvpn-endpoint-ID.prod.clientvpn.REGION.amazonaws.com
ss -tnp | grep -E ':(443|1194)'ואז השוו שלושה דברים: שם נקודת הקצה שהפרופיל מחזיק, הכתובת שהלקוח מדווח עבור ניסיון חדש, ולמה השם נפתר כעת. שם שנפתר מוכיח רק שהרשומה עונה; תעבורה ואימות נפרדים, ונקודת הקצה אינה חייבת להשיב ל-ping. היומן של הלקוח עצמו הוא המקור היחיד לפריט האמצעי, אז לכדו אותו במהלך הניסיון ולא אחריו.
| What you see | Usual cause | Next check |
|---|---|---|
| One machine fails, others connect | Pinned address or stale hosts entry on that machine | Diff its profile and hosts file against a working copy |
| Everyone fails at once, no config change | The endpoint address rotated | Confirm the current endpoint configuration with the account owner |
| Tunnel up, internal names fail | Client DNS policy, not endpoint resolution | Inspect the resolver pushed after connection |
כתובת שעונה היום היא ראיה על היום; השם הוא מה שהשירות שומר בתוקף. רשמו את התצפית, שלחו אותה למי שמחזיק בנקודת הקצה, והשאירו את הפרופיל מצביע על השם.
שני הרגלים שיש לנטוש: השבתת בדיקות תעודה כדי לעבור לחיצת יד תקועה, וערימת תוויות לפני שם נקודת הקצה בתקווה שאחת תיתפס. תווית נפתרת דרך רשומת ה-wildcard או שהבעיה במקום אחר. אם פרופיל מוגדר כהלכה עדיין נכשל, שלחו את השאילתה המדויקת ואת אירוע החיבור, לא שם מארח ארוך יותר.
לפני שסוגרים: הפרופיל עדיין נושא את שם נקודת הקצה המיוצא, שום קובץ hosts אינו נועץ את הכתובת, ה-remote ביומן הלקוח תואם פתרון עדכני, וכלל חומת האש נוקב בשם נקודת הקצה ולא בכתובת. זה גם המצב למסור לאדם הבא.