Azure VPN Client Linux-ում. DNS տիրույթները չհաջողվեց սահմանել

Թունելը բարձրանում է, և հետո Linux-ի հաճախորդը չի կարողանում սահմանել DNS տիրույթները: Ստուգեք systemd-resolved-ը, դիտարկեք D-Bus կանչը և ուղղեք polkit գործողությունը:

Թունելը բարձրանում է, վկայագիրը վավերացվում է, և հետո երկխոսությունը հայտնում է, որ DNS սերվերը կամ տիրույթները չհաջողվեց սահմանել: Linux-ում այդ երկխոսությունը սովորաբար դարպասի մասին չէ. հաճախորդը անվանման կազմաձևը D-Bus-ով փոխանցում է systemd-resolved-ին, և մերժված փոխանցումը թողնում է ինտերֆեյսը բարձրացված, երբ անվանումների լուծումը դեռ ցույց է տալիս հին կապին. Նույն նոթբուքը անվանումները լուծում է նորմալ, մինչև պրոֆիլը վերջածանց ստանա, և սա այն հուշումն է, որ արժե հետևել: Թունելում ոչինչ չփոխվեց այն պահին, երբ հայտնվեց երկխոսությունը:

Առանց վերջածանցի հաճախորդը ուղարկում է միայն անվանումների սերվերներ: Ավելացրեք որոնման տիրույթ, և երկրորդ կանչը միանում է դրան, 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 նոթբուքը դարձնում են կարճ ուղղում՝ կրկնվող հետաքննության փոխարեն:

Առնչվող հոդվածներ