DNS פרטי של Azure מעל VPN: נקודת קצה של resolver או forwarder
שני העיצובים עונים לאזורים פרטיים דרך המנהרה. השוו נקודת קצה נכנסת מנוהלת מול VM של forwarder, ואז בדקו את המסלול שחייב להתקיים בכל מקרה.
שרת ברשת המקומית מגיע ל-VM של Azure בכתובת פרטית ועדיין אינו מצליח לפתור את שם המארח הפרטי שלו, מה ששולח אנשים לחפש מנהרה שבורה. המנהרה תקינה. מה שחסר הוא גבול DNS: דבר בצד המקומי אינו יודע שאזור פרטי מסוים של Azure צריך להיענות על ידי resolver בתוך ה-VNet. שני עיצובים סוגרים את הפער הזה, והם נבדלים במה שאתם מפעילים בסופו של דבר, לא בכך אם השאילתות עובדות.
המנהרה נושאת שאילתות, לא ידע על אזורים
חיבור site-to-site נותן לחבילות מסלול בין שתי הרשתות. הוא אינו אומר לשרת ה-DNS המקומי איזה מרחב שמות שייך ל-Azure או איזו כתובת אמורה להשיב, ולכן השאילתה או יוצאת לאינטרנט וחוזרת ריקה, או שאינה עוזבת לעולם את ה-resolver המקומי.
לתיקון שני חצאים שקל להפריד. חצי אחד הוא resolver בתוך ה-VNet שמקבל שאילתות שמגיעות דרך המנהרה. החצי השני הוא forwarder מותנה בצד המקומי ששולח בדיוק מרחב שמות אחד לאותו resolver. אף חצי אינו עובד לבדו.
נניח שהאזור הוא cloud.corp.example להמשך התיאור, והתייחסו לכל כתובת כמשמעת.
אפשרות A: נקודת הקצה הנכנסת המנוהלת
Azure DNS Private Resolver מספק נקודת קצה נכנסת שמקבלת שאילתות DNS מחוץ ל-VNet. אתם פורסים אותה בתת-רשת מוקצית ומואצלת, מקשרים את האזור הפרטי לאותה VNet, ורושמים את כתובת הכניסה שהשירות מקצה.
בשרת ה-DNS המקומי יוצרים לאחר מכן forwarder מותנה עבור מרחב השמות המדויק לעבר אותה כתובת:
Namespace: cloud.corp.example
Forward to: 10.20.2.4הנוהל DNS היברידי של Microsoft מתעד גם את קישור האזור וגם את שלב ה-forwarder. המסלול המנוהל לא משאיר לכם תוכנת DNS לתקן, וכתובת נקודת הקצה נשארת יציבה לאורך חיי המשאב.
המחיר הוא שכעת יש לכם משאב resolver, האצלת תת-הרשת שלו והעלות שלו, שהיא אמיתית גם כשנפח השאילתות זעיר.
אפשרות B: VM forwarder בתוך ה-VNet
העיצוב הישן מריץ תוכנת DNS על VM רגיל ב-VNet: Windows DNS, BIND או dnsmasq, כשהאזור הפרטי מתארח מקומית או מועבר ל-resolver של Azure בכתובת 168.63.129.16. ה-forwarder המותנה המקומי מצביע לכתובת הפרטית של אותו VM.
אפשרות זו מוכרת לצוותים שכבר מפעילים שרתי DNS, והיא יכולה לשאת לוגיקה נוספת כמו רישום ביומן או תשובות split-horizon. היא גם יורשת כל חובת תפעול של שרת DNS: תיקון, מופע שני לזמינות, ניטור ומסלול בנייה מחדש כשמחליפים את ה-VM וכתובתו משתנה.
מארח VNet רגיל אינו פרוקסי DNS עד שהשירות מותקן ומורשה להשיב לאותם לקוחות, וזה בדיוק השלב שאנשים מדלגים עליו כשהם משכפלים VM.
איזה מתאים לתפעול שלכם
ההשוואה אינה בשאלה איזה עיצוב מהיר יותר. היא בשאלה אם אתם רוצים להפעיל תוכנת DNS בכלל, ואם נפח השאילתות מצדיק משאב מנוהל שמחייב לפי נקודת קצה ולפי שאילתה.
| Question | Managed inbound endpoint | Forwarder VM |
|---|---|---|
| Software to patch | None | The DNS service on every instance |
| Address stability | Fixed for the resource lifetime | Tied to the VM or its reserved address |
| Availability work | Handled by the service | Second instance, health checks, failover |
| Extra logic | Limited to resolver features | Whatever the DNS software supports |
איזה שורה שתכריע, כלל ה-forwarder המקומי נראה זהה. זה החלק שחייב להתקיים בשני העיצובים, וזה החלק שחסר לרוב כשמישהו מדווח שהפתרון עובד מתוך Azure אבל לא מהמשרד.
בדקו את המסלול לפי הסדר
ודאו שהאזור מקושר ל-VNet שמחזיקה את ה-resolver, ושה-forwarder המקומי מציין את מרחב השמות ולא תחום אב. forwarder עבור corp.example לא יתאים ל-cloud.corp.example אלא אם ה-resolver עצמו מאציל, וחוסר ההתאמה מייצר תשובה שלילית נקייה שנראית כמו רשומה חסרה.
לאחר מכן בדקו שהשאילתה מגיעה לנקודת הקצה: המקור המקומי צריך מסלול לכתובת ה-resolver ומסלול חזור, ויש לאפשר את פורט 53 גם ב-UDP וגם ב-TCP היכן שהמדיניות מאפשרת. NSG לא יכול לספק רשומת אזור חסרה, ואזור תקין לא יכול להשיב לשאילתה שלעולם אינה מגיעה.
שמרו את ה-FQDN המבוקש לצד ה-resolver שבחרתם כשאתם מאבחנים, והפרידו בין פסק זמן לתשובה שלילית. פסק זמן הוא בעיית מסלול או מדיניות. תשובה שלילית פירושה שהשאילתה הגיעה ומרחב השמות לא התאים. סדר העבודה: קשרו את האזור, הוסיפו את ה-forwarder המותנה, פתחו את פורט 53 בשני הכיוונים, בדקו שם אחד מהמקום, ורק אחר כך הסתכלו על ההרשאה של היישום עצמו.