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

Подобни статии