Тунэль падымаецца, сертыфікат правяраецца, і тут дыялог паведамляе, што 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 кароткім выпраўленнем, а не паўторным расследаваннем.

Падобныя артыкулы