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 в короткое исправление, а не повторное расследование.

Похожие статьи