לעצור שני שירותי לינוקס שמתחרים על /etc/resolv.conf

DNS חוזר שוב ושוב למצבו הקודם, החיבור מחדש של ה-VPN מבטל את התיקון שלכם, ובסוף מישהו בצוות מציע לנעול את הקובץ. הרצף הזה הוא סימפטום, לא פתרון: שני רכיבים חושבים שניהם שהם הבעלים של /etc/resolv.conf, ומי שכותב אחרון מנצח. נעילת הקובץ אינה פותרת את קונפליקט הבעלות, היא רק מסתירה אותו ובמקביל שוברת את הרכיב שאתם באמת רציתם. עברו על ארבע הבדיקות שלהלן לפי הסדר, ותקנו את הסידור ברמה שבבעלותה הוא נמצא, לא בקובץ.

בדיקה 1: האם זה קישור סמלי, ולאן

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

ls -l /etc/resolv.conf
readlink -f /etc/resolv.conf
cat /etc/resolv.conf

קישור לנתיב stub של systemd-resolved פירושו שתוכן הקובץ נוצר, ושעריכה ידנית תידרס באירוע הבא. קובץ רגיל עם שורות nameserver נכתב בדרך כלל על ידי הלקוח או ה-hook של DHCP שפועל בעת החיבור. שניהם לגיטימיים; מה שחשוב הוא לדעת איזה מהם יש לכם לפני שאתם משנים משהו.

בדיקה 2: איזה דימון פועל

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

systemctl status systemd-resolved --no-pager
resolvectl status
ss -lunp | grep ':53'

פלט הסטטוס מציין את שרתי ה-DNS לכל קישור ואת דומיינים הניתוב, וזה המפה שאתם צריכים ל-split DNS. אם שמות פנימיים חייבים ללכת לשרת פנימי וכל השאר לשרת ציבורי, המדיניות הזו חיה בדומיינים לכל קישור, ושיטוחה לרשימת nameserver סטטית בקובץ מאבד את ההבחנה הזו בשקט.

התצורה של NetworkManager עצמו קובעת באיזה מה-backends האלה הוא משתמש. ההגדרה dns= שלו בקובץ התצורה הראשי בוחרת בין הפותר הפנימי שלו, dnsmasq, systemd-resolved ו-none, וייתכן שההפצה בחרה עבורכם. קראו את ההגדרה הזו לפני שתחליטו מה המשמעות של “לתקן DNS” במארח הזה.

בדיקה 3: מה לקוח ה-VPN רשאי לכתוב

כאן בדרך כלל חי הקונפליקט. לקוח VPN שכותב מחדש את קובץ הפותר ישירות ייאבק בכל שירות שגם מתחזק אותו, והמפסיד הוא מי שרץ ראשון. גרסאות חדשות של OpenVPN יכולות להעביר את הגדרות ה-DNS ל-systemd-resolved במקום לכתוב מחדש את הקובץ, וזו ההתנהגות המשתפת שאתם רוצים; סקריפטים ישנים יותר ו-hooks שנכתבו ביד קוראים לעתים קרובות לכלי עזר מיושן או פשוט כותבים על הקובץ.

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

קראו את ה-hooks של העלאה והורדה של הלקוח במקום לנחש. כמה שורות shell ב-/etc/openvpn/up.sh או בתיקייה מקבילה מסבירות התנהגות שנראית אחרת אקראית, והן גם המקום שבו אפשר לגרום ללקוח לשתף פעולה במקום להתחרות.

בדיקה 4: תקנו אצל הבעלים, לא בקובץ

לאחר שתדעו מי הבעלים, הגדירו DNS דרך הממשק הנתמך של אותו בעלים. עבור systemd-resolved זה אומר הגדרות לכל קישור ודומיינים של ניתוב במקום קובץ סטטי; עבור NetworkManager זה אומר הגדרות ה-DNS של פרופיל החיבור וה-backend שנבחר; עבור הפצה שמשתמשת באינטגרציית resolvconf זה אומר לכתוב דרך עוזר זה.

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

כששני רכיבים באמת חייבים להתקיים יחד, תנו להם תפקידים שונים. תנו למנהל הרשת להחזיק בתצורה ברמת הממשק, תנו ללקוח ה-VPN לתרום DNS ודומיינים לכל קישור דרך אותה אינטגרציה, והסירו את הסקריפט השלישי שכותב את הקובץ ישירות. התיעוד של systemd-resolved מפרט את המצבים שהוא תומך בהם ומה כל אחד מהם חושף ב-/etc/resolv.conf. בחרו את המצב שמתאים לכמות המדיניות שעליכם לשמור. אם split DNS חשוב, סידור ה-stub עם דומיינים לכל קישור משמר אותו, בעוד המצב שמעתיק שרתים במעלה הזרם לקובץ משטח אותו בשקט.

אמתו אחרי חיבור מחדש, לא אחרי העריכה

קובץ שנראה תקין מיד אחרי השינוי שלכם אינו מוכיח דבר, מפני שהאירוע הבא עדיין לא התרחש. הפעילו את הרצף שפעם שבר אותו: הורידו והעלו את המנהרה, חדשו את חכירת ה-DHCP או החליפו את הממשק, ואז קראו שוב את אותם ערכים.

resolvectl query build.corp.example
resolvectl query example.com
resolvectl status | head -40

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

רשמו את הבעלים, את ה-backend ואת מצב הקישור הסמלי בהערות הפריסה. הפסקה האחת הזו הופכת שדרוג חבילה עתידי מתקרית לפריט סקירה, והיא מונעת מהאדם הבא לגלות מחדש את אותו קונפליקט עם פקודת chattr.