DNS פרטי עובד ב-VPC אך לא דרך VPN
שם פרטי שנפתר בתוך EC2 אך לא דרך VPN הוא בעיה בנתיב ה-resolver. קראו את צורת הכשל לפני שתערכו את רשומת האזור.
שם פרטי נפתר ממופע EC2 אך לא ממחשב נייד המחובר דרך VPN, והאזור נראה תקין בקונסולה. הדחף הראשון הוא לערוך את הרשומה, וזה כמעט אף פעם לא הבעיה. הרשומה עונה למישהו; היא פשוט לא עונה למחשב הנייד שלכם. מה ששונה בין שני הפונים הוא איזה resolver הם שואלים והאם לאותו resolver יש נתיב נתמך אל תצוגת ה-DNS של ה-VPC.
אני מתחיל בהוכחה שהרשומה קיימת, ואת שאר הזמן מקדיש לנתיב השאילתה. אלה מערכות נפרדות והן נכשלות בצורות שונות.
קראו את צורת הכשל לפני שתשנו משהו
שלוש תוצאות פירושן שלושה דברים שונים, ושאילתה אחת מבדילה ביניהם: הריצו dig עבור השם מול ה-resolver שהלקוח באמת משתמש בו.
| What you see | What it usually means | First thing to check |
|---|---|---|
| SERVFAIL, or a timeout after several seconds | No path to the resolver, or the resolver cannot reach AWS | Route to the endpoint and the security policy on port 53 |
| NXDOMAIN from a resolver that did answer | The resolver replied, but the zone is not in its view | Zone association or the forwarding rule for that namespace |
| A public address for an internal name | Split DNS is not in effect for this client | Which resolver the client is configured to use |
פסק זמן הוא הצהרה על הרשת. NXDOMAIN היא הצהרה על תצוגת ה-DNS. תשובה ציבורית היא הצהרה על המדיניות. עריכת רשומת אזור בזמן שיש פסק זמן זורקת את הראיה השימושית היחידה בתיק.
למה כתובת הפלוס שתיים של ה-VPC אינה resolver מרוחק
כתובת ה-CIDR פלוס שתיים היא שירות מקומי למשאבים בתוך ה-VPC. AWS מתעדת שהעברת שאילתות מרשתות מקומיות, או משרתי ה-DNS של VPC אחר, ישירות לכתובת הזו אינה נתמכת ועלולה להניב תוצאות לא יציבות.
זה לא אומר שניסוי אף פעם לא נראה עובד. זה אומר שההתנהגות אינה חוזה שאפשר לשים בסקריפט תמיכה. הכיוון הנתמך הוא נקודת קצה נכנסת של Resolver: זוג כתובות בתוך ה-VPC שלכם, נגיש מהרשת שאתם שולטים בה, שמקבל שאילתות המגיעות מחוץ ל-AWS.
בנו את הנתיב בסדר שבו הוא נכשל באופן נקי
חייבות להתקיים שלוש קפיצות, ולכל אחת דרך כשל משל עצמה.
VPN client -> approved DNS forwarder
forwarder -> forwarding rule for internal.example
forwarding rule -> Resolver inbound endpoint addressesהמעביר צריך נתיב לכתובות נקודת הקצה דרך ה-VPN, וגם נתיב החזור חייב לעבוד. עבור DNS קונבנציונלי בפורט 53 נקודת הקצה עונה דרך UDP ו-TCP, ולכן שני הפרוטוקולים חייבים להיות מותרים ושניהם חייבים לשרוד כל בדיקת מצב בדרך.
לאחר מכן בדקו את תצוגת ה-DNS בנפרד. אזור מתארח פרטי נראה רק ל-VPC שאליהם הוא משויך, או דרך הסדר שיתוף מכוון. נקודת קצה נגישה אינה הופכת מעצמה כל אזור פרטי לפתיר בהקשר הפתרון שלו.
נקודת קצה יוצאת משרתת את הכיוון ההפוך ולא תענה לשאילתה שמגיעה מהמחשב הנייד שלכם.
אמתו משני הקצוות
שאלו מהלקוח אל המעביר, ואז מהמעביר אל נקודת הקצה. אם הלקוח נכשל בעוד המעביר מצליח, הפער הוא בין השניים.
אם שניהם נכשלים, הסתכלו במדיניות האבטחה בנקודת הקצה ובכתובת המקור שהיא באמת רואה. מעביר מאחורי NAT מציג את כתובת ה-NAT במקום כתובת ה-VPN של המחשב הנייד, וההבדל הזה לבדו מספיק כדי להפיל את השאילתה. אם שניהם מצליחים אך האפליקציה עדיין נכשלת, ייתכן שהאפליקציה משתמשת ב-resolver אחר מזה שבדקתם.
החזיקו את מרחבי השמות הציבוריים והפרטיים בנפרד בכוונה. Split DNS היא מדיניות שאתם מגדירים, לא תופעת לוואי של חיפוש אחד שבמקרה מחזיר נתונים.
מה לא הייתי עושה
לא הייתי מוסיף כלל NAT שהפעיל חיפוש אחד וקורא לזה עיצוב.
לא הייתי מפנה כל לקוח מרוחק לכתובת הפלוס שתיים רק מפני שבדיקה אחת החזירה רשומה פעם אחת. ולא הייתי מרחיב את מדיניות האבטחה של נקודת הקצה לכל מאגר ה-VPN כשמעביר אחד צריך גישה. אם הארגון כבר מפעיל מעביר מאושר בתוך ה-VPC, קראו קודם את העיצוב הזה, כי נקודת הקצה השנייה שתוסיפו היא זו שאיש לא מתעד.