Azure VPN Client บน Linux: ตั้งค่าโดเมน DNS ไม่ได้

อุโมงค์เชื่อมต่อขึ้นมา ใบรับรองผ่านการตรวจสอบ แล้วก็มีกล่องโต้ตอบบอกว่าไม่สามารถตั้งค่าเซิร์ฟเวอร์ DNS หรือโดเมนได้ บน Linux กล่องนั้นมักไม่เกี่ยวกับเกตเวย์: ไคลเอนต์ส่งมอบการตั้งค่าชื่อให้ 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 ที่ล้มเหลว ไฟล์กฎ และเวอร์ชันโปรไฟล์ลงในตั๋ว สี่บรรทัดนั้นทำให้แล็ปท็อป Linux เครื่องถัดไปเป็นการแก้ไขสั้น ๆ แทนการสอบสวนซ้ำ