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-ზე მიმართულ სიმბოლურ ბმულს და resolvectl-ში თითოეული კავშირის DNS-ს. როცა მფლობელობა 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 მოქმედების დაშვება უფრო ფართოა, ვიდრე ამ კლიენტს სჭირდება, და მოგვიანებით გაცილებით რთული შესამოწმებელი.
polkit-ის რედაქტირებამდე შეამოწმეთ პროფილის XML
ხელით რედაქტირებული პროფილი შეიძლება უსიტყვოდ იქნას იგნორირებული. Microsoft ბრტყელ განლაგებას ასაბუთებს, სადაც dnsserver ჩანაწერები პირდაპირ dnsservers-შია, ხოლო სუფიქსები dnssuffixes-ში. ყოველი მისამართის ირგვლივ დამატებითი გარსი ეს ფორმა არ არის, და კლიენტი ჩუმად უბრუნდება იმას, რასაც შესახვევი აგზავნის.
polkit-ს შეხებამდე გააკეთეთ წაშლის ტესტი. მოხსენით სუფიქსის ბლოკი, ხელახლა დაუკავშირდით და ნახეთ, იცვლება თუ არა დიალოგი. თუ იცვლება, ჩავარდნილი გამოძახება დომენის გადაცემა იყო, და შესწორება ავტორიზაციაა და არა კიდევ ერთი XML რედაქტირება.
შეამოწმეთ დომენი გვირაბის კავშირზე
ხელახლა დაუკავშირდით და ისევ წაიკითხეთ resolvectl status, შეამოწმეთ, რომ გვირაბის კავშირი ერთად ატარებს სახელების სერვერს და საძიებო დომენს. ამოხსენით მოკლე კერძო სახელი და არა საჯარო. როცა სახელი იხსნება, მაგრამ მის უკან მდგარი სერვისი არ პასუხობს, DNS გადაცემა იმუშავა და დარჩენილი პრობლემა მარშრუტიზაციაა.
ბილეთში ჩაწერეთ ამომხსნელის მფლობელი, ჩავარდნილი D-Bus გამოძახება, წესის ფაილი და პროფილის ვერსია. ეს ოთხი ხაზი შემდეგ Linux ლეპტოპს განმეორებითი გამოძიების ნაცვლად მოკლე შესწორებად აქცევს.