WireGuard לא דוחף DNS: הגשת אזור BIND פרטי

העליתם את WireGuard, המנהרה מעבירה תנועה, והשם הפנימי עדיין לא נפתר. הצעד הבא הוא בדרך כלל לחפש הגדרת DNS בתצורת WireGuard, כאילו עמית יכול לדחוף resolver כפי שחלק מה-VPNs האחרים עושים. הוא לא יכול. לחיצת היד נושאת מפתחות, כתובות ממשק וכתובות IP מותרות, ואין בה שדה לשרתי DNS או לתחומי חיפוש. מדיניות ה-resolver חיה בלקוח, ושם מקום התיקון.

המנהרה וה-resolver הם חוזים נפרדים

WireGuard קטן בכוונה. הוא מעביר מנות לכתובות שאתם מפרטים ומאמת עמיתים; כל מה שמעל לשכבה הזו הוא העיצוב שלכם. OpenVPN יכול לדחוף dhcp-option DNS מפני שערוץ הבקרה שלו נושא תצורה, וההבדל הזה מכשיל אנשים שעוברים בין השניים.

אז מנהרה שעובדת לא אומרת לכם דבר על פתרון שמות. ללקוח יכולה להיות מסלול מושלם אל 10.90.0.1 והוא עדיין ישלח את השאילתות שלו ל-resolver ציבורי, ולכן התסמין נראה כמו “ה-VPN שבר את ה-DNS” כשבפועל ה-DNS מעולם לא הופנה אל ה-VPN.

הגישו את האזור בלי להפוך ל-resolver רקורסיבי

צד השרת הוא אזור סמכותי קטן, לא resolver כללי. בדוגמה הזו השער הוא 10.90.0.1, הלקוחות הם 10.90.0.0/24, והיישום שמעניין אתכם עונה בכתובת 10.60.0.20.

מזגו את ההגדרות האלה אל בלוק options הקיים במקום ליצור בלוק שני:

options {
    listen-on { 127.0.0.1; 10.90.0.1; };
    listen-on-v6 { none; };
    allow-query { 127.0.0.1; 10.90.0.0/24; };
    allow-transfer { none; };
    recursion no;
};

אחר כך הכריזו על האזור ועל הקובץ שלו:

zone "corp.example" {
    type primary;
    file "/etc/bind/db.corp.example";
};

$TTL 300
@ IN SOA ns.corp.example. hostmaster.corp.example. ( 1 3600 600 604800 300 )
@      IN NS ns.corp.example.
ns     IN A  10.90.0.1
portal IN A  10.60.0.20

אמתו לפני טעינה מחדש, כי שגיאת תחביר בזמן טעינה מפילה את כל השרת לכל אזור שהוא מגיש:

named-checkconf
named-checkzone corp.example /etc/bind/db.corp.example

פתחו UDP ו-TCP 53 רק בממשק ה-VPN. פרסום סמכות פרטית בממשק הציבורי מזמין גם שאילתות וגם ספירה, ו-allow-transfer צריך להישאר סגור אלא אם כן שרת משני באמת זקוק לו.

כוונו את הלקוח אליו, לכל קישור

הניחו ש-NetworkManager מחזיק בחיבור ושה-resolver הוא systemd-resolved. קראו קודם את המדיניות הקיימת, במיוחד כל תחום ניתוב שורש, כי רשומת ~. תעקוף את מה שאתם עומדים להוסיף.

nmcli connection modify wg-office +ipv4.dns 10.90.0.1
nmcli connection modify wg-office +ipv4.dns-search '~corp.example'

הטילדה היא התו החשוב. היא מסמנת את התחום כניתוב בלבד: שמות תחת corp.example הולכים לשרת ה-DNS של הקישור הזה, והתחום אינו מתווסף כסיומת חיפוש לשמות קצרים. בלעדיה, הקלדת portal מתחילה לפתור portal.corp.example, מה שנוח לכם ומפתיע לכל השאר. השאירו את הטילדה בתוך המרכאות, כי טילדה בלי מרכאות היא הרחבת מעטפת שממתינה להצביע על תיקיית הבית שלכם.

החילו את השינוי דרך המנהל שמחזיק בממשק, ואז חברו מחדש את החיבור. אל תפעילו מופע שני של wg-quick לאותו ממשק; שני בעלים יריבו על מסלולים ואחד מהם ינצח ברגע הגרוע ביותר.

אמתו את המסלול לפני השם

שאלו את השם מהלקוח ואשרו גם את התשובה וגם את השרת שהפיק אותה:

resolvectl query portal.corp.example

אם זה מחזיר 10.60.0.20, חוזה ה-DNS מולא. אם זה נגמר בזמן, בדקו קודם את המסלול אל 10.90.0.1, אחר כך את כלל חומת האש, ואחר כך allow-query בשרת. כשלי פתרון שמות בהתקנה הזו הם כמעט תמיד נגישות או ACL, לא קובץ האזור. עבדו מהלקוח החוצה, כי השרת לא יכול לספר לכם למה שאילתה מעולם לא הגיעה.

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

מה שעדיין לא אוטומטי

יישומים עם לוגיקת resolver משלהם מתעלמים לגמרי מה-resolver של המערכת, וכל כמות של nmcli לא תשנה זאת. פריסות שמאמתות DNSSEC זקוקות לעיצוב עוגן אמון מפורש לאזור הפרטי; התשובה אינה הוראה גורפת לכבות אימות. בדקו עם אותה תוכנת לקוח שהמשתמשים שלכם מריצים, לא עם כלי שמשתמש במקרה ב-resolver של המערכת. הפער בין השניים הוא כל דוח התקלה.

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

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