Azure VPN Client у Linux: не вдалося задати домени DNS

Тунель піднімається, і тут клієнт Linux не може задати домени DNS. Перевірте systemd-resolved, простежте виклик D-Bus і виправте дію polkit.

Тунель піднімається, сертифікат перевіряється, і тут діалог повідомляє, що сервер 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 на коротке виправлення, а не повторне розслідування.

Схожі статті