DNS מפוצל מעל OpenVPN: מה צריך דומיין ניתוב לעשות בכל מערכת הפעלה

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

תנו שם למדיניות קודם, ואז בחרו בפרימיטיב של הפלטפורמה שמבטא אותה.

שלוש הגדרות שקל לבלבל ביניהן

סיומת חיפוש מרחיבה שם קצר: הקלדת files הופכת ל-files.corp.example כשהפותר מנסה את הסיומות לפי הסדר. דומיין ניתוב בוחר איזה פותר עונה לשאילתות בתוך מרחב שמות. נתיב IP רק הופך את הפותר שנבחר לנגיש. שלושת אלה חיים בשכבות שונות, והחלפת אחד באחר מייצרת תצורה שנראית נכונה ולא פותרת כלום.

לבלבול יש מחיר: הוספת סיומת חיפוש שולחת כל שם קצר לפותר של העבודה, כולל שמות ששייכים למקום אחר. בחירת דומיין ניתוב משאירה שאילתות לא קשורות בפותר המקומי ובכל זאת שולחת *.corp.example דרך המנהרה.

Linux: דומיין ניתוב בלבד, לא סיומת חיפוש

ב-systemd-resolved, דומיין עם טילדה בהתחלה הוא דומיין ניתוב בלבד, כלומר שאילתות לאותו מרחב שמות הולכות לפותר המקושר בלי להפוך גם לסיומת חיפוש. resolvectl domain tun0 '~corp.example' מגדיר זאת, ו-resolvectl dns tun0 10.8.0.1 נותן שם לשרת. שתי ההגדרות שייכות לממשק, ולכן הן נעלמות איתו. הטילדה היא החלק שאנשים משמיטים, ובלעדיה שמות קצרים מתחילים להיפתר דרך הפותר של העבודה.

אל תתקינו גם את אותו דומיין כסיומת חיפוש גלובלית. שתי ההגדרות אינן מיותרות; האחת מנתבת והשנייה משכתבת את מה שהקלדתם.

Windows צריך מדיניות מרחב שמות, לא סיומת

Windows שומר את מדיניות ה-DNS המפוצל ב-Name Resolution Policy Table, ולא בסיומת ה-DNS של המתאם. כלל ממפה מרחב שמות לשרתים מסוימים: Add-DnsClientNrptRule -Namespace .corp.example -NameServers 10.8.0.1. הגדרת הסיומת לבדה משנה איך נראים שמות קצרים; היא לא מפנה את השאילתה לשרת אחר.

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

החזיקו בעלים אחד לפותר בכל פלטפורמה

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

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

אשרו את התוצאה, לא את טקסט הפרופיל

פתרו שם אחד שאמור לעבור דרך המנהרה ואחד שלא, בכל פלטפורמה, ואשרו איזה שרת ענה. resolvectl query host.corp.example ו-Resolve-DnsName host.corp.example מדווחים שניהם על השרת שהגיב. חזרו על כך אחרי חיבור מחדש. אחר כך אשרו שהפותר של המנהרה נגיש בכתובת שהפרופיל דוחף, כי מדיניות נכונה שמצביעה על שרת לא נגיש נכשלת בדיוק כמו היעדר מדיניות.

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