Azure VPN Client בלינוקס: לא ניתן היה להגדיר דומייני DNS

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

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

ודאו ש-systemd-resolved הוא הפותר

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

שלוש פקודות מכריעות את זה:

systemctl status systemd-resolved
ls -l /etc/resolv.conf
resolvectl status

אתם מחפשים שירות פעיל, קישור סמלי שמצביע על /run/systemd/resolve/stub-resolv.conf, ו-DNS לכל קישור ב-resolvectl. כשהבעלות היא של NetworkManager, העבירו אותה ל-resolved במקום להילחם בלקוח; קובץ ה-drop-in שלמטה מגדיר את שני המפתחות:

[main]
dns=systemd-resolved
systemd-resolved=true

הפעילו מחדש את NetworkManager ברגע שהקובץ קיים. פותר לא פעיל יחד עם לקוח שממשיך לקרוא בשמו ב-D-Bus יוצר שגיאה שלא נוקבת בשניהם.

עקבו אחר קריאת ה-D-Bus שנכשלת

השלב הזה הופך את התיבה לתשובה מדויקת. עקבו אחר ממשק הפותר במסוף אחד ואחר היומן במסוף אחר, ואז התחברו מחדש:

sudo dbus-monitor --system "interface='org.freedesktop.resolve1.Manager'"
journalctl -fu systemd-resolved

שלוש קריאות אמורות להופיע: SetLinkDNS, SetLinkDomains ו-SetLinkDefaultRoute. זו שחוזרת כתשובת שגיאה היא זו שצריך לתקן. התשובה הזו בדרך כלל מציינת את הסיבה, למשל org.freedesktop.DBus.Error.AccessDenied מול SetLinkDomains. רשמו איזו קריאה הייתה, כי החלק הבא עוסק בהעברת אותה קריאה.

העניקו ללקוח את פעולות ה-polkit שהוא צריך

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

pkaction --verbose --action-id org.freedesktop.resolve1.set-domains
pkaction --action-id org.freedesktop.resolve1.set-dns-servers --verbose

אם התשובה היא auth_admin_keep, הלקוח צריך כלל מפורש. הקטע שלמטה מתיר את ארבע פעולות ה-resolve1 שלקוח VPN משתמש בהן בזמן חיבור ומשאיר כל דבר אחר ב-polkit.Result.NOT_HANDLED:

polkit.addRule(function(action, subject) {
  var allowed = [
    "org.freedesktop.resolve1.set-dns-servers",
    "org.freedesktop.resolve1.set-domains",
    "org.freedesktop.resolve1.set-default-route",
    "org.freedesktop.resolve1.revert"
  ];
  if (allowed.indexOf(action.id) !== -1 &&
      subject.isInGroup("wheel")) {
    return polkit.Result.YES;
  }
  return polkit.Result.NOT_HANDLED;
});

שימו אותו ב-/etc/polkit-1/rules.d/ כקובץ שתזהו אחר כך, למשל 50-azurevpn.rules, והחליפו את שם הקבוצה בקטע בשם שלכם לפני התנתקות והתחברות מחדש. שמרו אותו צר, כי התרת כל פעולת resolve1 לכל חשבון רחבה ממה שהלקוח הזה צריך והרבה יותר קשה לביקורת מאוחר יותר.

בדקו את ה-XML של הפרופיל לפני עריכת polkit

פרופיל שנערך ביד יכול להיתעלם בלי מילה. Microsoft מתעדת פריסה שטוחה שבה ערכי dnsserver יושבים ישירות בתוך dnsservers, והסיומות בתוך dnssuffixes. רכיב עטיפה נוסף סביב כל כתובת אינו הצורה הזו, והלקוח נופל בשקט למה שהשער דוחף.

עשו את מבחן ההסרה לפני שנוגעים ב-polkit. הסירו את בלוק הסיומת, התחברו מחדש וראו אם התיבה משתנה. אם כן, הקריאה שנכשלה הייתה מסירת הדומיין, והתיקון הוא הרשאה ולא עוד עריכת XML.

אמתו את הדומיין בקישור המנהרה

התחברו מחדש וקראו שוב resolvectl status, ובדקו שקישור המנהרה נושא את שרת השמות ואת דומיין החיפוש יחד. פענחו שם פרטי קצר ולא שם ציבורי. כשהשם מפוענח אבל השירות שמאחוריו לא עונה, מסירת ה-DNS עבדה והבעיה שנותרה היא ניתוב.

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