BIND מעל VPN: העברה מותנית או אזור stub?
שלוש דרכים לפתור אזור פרטי אחד דרך VPN, ומתי כל אחת מתאימה: forward, stub או secondary, בתוספת בדיקת כתובת המקור שמכריעה.
ה-resolver של המשרד עונה על הכול מלבד מרחב שמות ארגוני אחד, ושרת ה-DNS הארגוני שמכיר אותו נמצא מאחורי VPN. BIND יכול למסור את האזור הבודד הזה ל-upstream בשלוש דרכים שונות, והן נכשלות באופן שונה. העברה מותנית היא ההתחייבות הקטנה ביותר, אזור stub שומר את נתוני ההאצלה, ו-secondary שומר עותק מלא. בחרו לפי מה שה-upstream יאפשר ולפי מה שאתם רוצים שה-resolver שלכם יחזיק, לא לפי איזה קטע קוד מצאתם קודם.
שלושה סידורים למרחב שמות אחד
| Type | What your resolver keeps | Upstream must | Fails when |
|---|---|---|---|
forward | a forwarder list | answer queries from your source address | upstream is down and forward only is set |
stub | the zone's NS records and addresses | answer NS queries for the zone | delegation data goes stale after an NS change |
secondary | a full copy of the zone | permit AXFR or IXFR from your source | transfer is blocked by ACL or firewall |
העברה מותנית: ההתחייבות הקטנה ביותר
נניח resolver משרדי בכתובת 192.168.10.53 ושרת ארגוני בכתובת 10.40.0.53 שנגיש דרך מנהרה מאושרת. ההצהרה היא שלוש שורות, והמעניינת היא forward only, מפני שהיא משנה את התנהגות הכשל ולא את המסלול.
zone "corp.example" {
type forward;
forward only;
forwarders { 10.40.0.53; };
};עם forward only, upstream שאינו נגיש מפיק SERVFAIL עבור האזור הזה במקום נסיגה לפתרון איטרטיבי. זו בדרך כלל הכוונה במרחב שמות פרטי, מפני שהנסיגה הייתה שולחת שמות פרטיים ל-resolver ציבורי ומחזירה תשובה חסרת תועלת מהאינטרנט. תיעוד BIND מתעד את שתי המדיניות, וההבדל חשוב יותר ממה שהקטע מרמז. מזגו את האזור לתוך התצורה הקיימת במקום להחליף אזור שכבר קיים עבור אותו שם.
stub או secondary: כאשר ההאצלה חשובה
אזור stub שואל את השרת הארגוני על רשומות ה-NS של האזור ואז שואל את השרתים המוסמכים ישירות. בחרו בו כאשר אזור ה-upstream גדול או מחולק ואתם רוצים שה-resolver שלכם ימשיך את ההאצלה במקום לנעוץ הכול בכתובת אחת. המחיר הוא תלות בכך שנתוני ה-NS עדכניים, ובכך שכל שרת שמות ברשימה נגיש מכתובת המקור של ה-resolver שלכם.
zone "corp.example" {
type stub;
masters { 10.40.0.53; };
};
zone "corp.example" {
type secondary;
primaries { 10.40.0.53; };
file "corp.example.db";
};secondary עונה מנתונים מקומיים ושורד את נפילת ה-upstream, וזו הסיבה לקבל את תלות ההעברה. משמעות הדבר גם שה-resolver שלכם מחזיק כעת עותק של אזור שאינו שלו, ולכן נתיב הקובץ, ה-ACL להעברה בשרת הראשי ומתזמני הרענון הופכים כולם לחלק ממשטח התפעול שלכם.
הבדיקה שמכריעה ביניהם
BIND מייצר את השאילתה היוצאת שלו בעצמו, ולכן השאלה אינה אם מחשב נייד יכול להגיע אל 10.40.0.53 אלא אם המארח של ה-resolver יכול, מכתובת המקור שהשרת הארגוני יראה. שאלו את הליבה, ואחר כך את השרת, בסדר הזה.
ip route get 10.40.0.53
named-checkconf
rndc reload corp.example
dig @10.40.0.53 corp.example NS +norecurse
dig @192.168.10.53 portal.corp.exampleאפשרו UDP ו-TCP במסלול: תשובה מקוצצת כופה TCP, ומדיניות שמאפשרת רק UDP מייצרת כשלים לסירוגין שנראים כמו אובדן פקטים. הצד הארגוני צריך גם כלל קבלה עבור המקור של ה-resolver שלכם וגם נתיב חזרה אליו; המקור הזה יכול להיות הכתובת המנותבת של ה-resolver או כתובת מתורגמת במפורש, והוא רק לעתים רחוקות כתובת של מאגר לקוחות. אם שאילתת ה-NS נכשלת, אזור stub לא יכול לעבוד, תהיה אשר תהיה התנהגות אזור ה-forward.
אמתו את התשובה, לא את המנהרה
שאלו דרך resolver המשרד על שם שמעולם לא ביקשתם, ובדקו את מקטע ה-authority של התשובה כדי לראות אם הוא בא מהאזור הארגוני. תשובה מהמטמון אינה מוכיחה דבר על המסלול הנוכחי, ושאילתה ישירה מוצלחת ל-upstream אינה מוכיחה שה-resolver שלכם בחר את האזור הזה. חזרו על אותה שאילתה דרך TCP כדי לאשר שהמסלול שורד קיצוץ.
השאירו את הלקוחות ממוקדים ל-resolver המשרדי, והשאירו את אימות ה-DNSSEC דלוק. דפדפן שמוגדר עם resolver מוצפן עצמאי עוקף את הסידור הזה לחלוטין, וכיבוי האימות כדי שתשובה לא צפויה תיראה נכונה מחליף כשל גלוי בכשל סמוי.
רשמו איזה משלושת הסוגים בחרתם ולמה. האדם הבא שיראה את האזור נכשל יצטרך את המשפט הזה יותר מאשר את קובץ התצורה.