ටනලය ඉහළ යයි, සහතිකය වලංගු වේ, පසුව 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 නම්, සේවාලාභියාට පැහැදිලි රීතියක් අවශ්‍යයි. පහත ස්නිපටය VPN සේවාලාභියා සම්බන්ධ වීමේදී භාවිත කරන resolve1 ක්‍රියා හතරට ඉඩ දෙන අතර අනෙක් සියල්ල 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 ලැප්ටොප් පරිගණකය නැවත පරීක්ෂාවක් වෙනුවට කෙටි නිවැරදි කිරීමක් බවට පත් කරයි.

අදාළ ලිපි