/etc/resolv.conf සඳහා තරඟ වදින Linux සේවා දෙක නවත්වන්න

ගොනුව සංස්කරණය කිරීමට පෙර එහි හිමිකරු කවුදැයි සොයා ගන්න. වෙනස් නොවන කොඩිය ගැටුම සඟවන අතර, නැවත සම්බන්ධ වීම් හෝ DHCP අලුත් කිරීම් අතින් කරන DNS අලුත්වැඩියාව නැවත නැවත අවලංගු කරයි.

DNS නැවත නැවත පැරණි තත්ත්වයට පැමිණේ, VPN නැවත සම්බන්ධ වීම ඔබේ නිවැරදි කිරීම අවලංගු කරයි, අවසානයේ කණ්ඩායමේ කෙනෙක් ගොනුව අගුළු දැමීමට යෝජනා කරයි. එම අනුපිළිවෙල රෝග ලක්ෂණයක් මිස විසඳුමක් නොවේ: සංරචක දෙකම /etc/resolv.conf තමන් සතු යැයි සිතයි, සහ අවසානයේ ලියන්නා ජය ගනී. ගොනුව අගුළු දැමීම හිමිකාරිත්ව ගැටුම විසඳන්නේ නැත, එය සඟවා තබන අතර ඔබට ඇත්තටම අවශ්‍ය වූ සංරචකය බිඳ දමයි. පහත සිව් පරීක්ෂණ පිළිවෙලට කර එය හිමි මට්ටමේ සැකසුම නිවැරදි කරන්න, ගොනුවේ නොවේ.

පරීක්ෂණය 1: එය සිම්බොලික් සබැඳියක්ද, කුමකටද

ගොනුවෙන්ම පටන් ගන්න, මක්නිසාද ඔබ සංස්කරණය කරන මාර්ගය ගොනුවම නොවිය හැකියි. විසඳන්නාගේ ධාවන නාමාවලියට යන සිම්බොලික් සබැඳියක්, සේවාදායක ස්ක්‍රිප්ටයක් නැවත ලියන සාමාන්‍ය ගොනුවකට වඩා සම්පූර්ණයෙන්ම වෙනස් ලෙස හැසිරේ:

ls -l /etc/resolv.conf
readlink -f /etc/resolv.conf
cat /etc/resolv.conf

systemd-resolved හි stub මාර්ගයකට සබැඳියක් යනු ගොනුවේ අන්තර්ගතය ජනනය වන බවයි, සහ අතින් සංස්කරණය ඊළඟ සිදුවීමේදී උඩින් ලියැවෙනු ඇත. nameserver පේළි සහිත සාමාන්‍ය ගොනුවක් සාමාන්‍යයෙන් ලියන්නේ සම්බන්ධ වන විට ධාවනය වන සේවාදායකය හෝ DHCP කොක්කයයි. දෙකම නීත්‍යානුකූලය; වැදගත් වන්නේ යමක් වෙනස් කිරීමට පෙර ඔබට ඇත්තේ කුමක්දැයි දැන ගැනීමයි.

පරීක්ෂණය 2: කුමන ඩේමන් ධාවනය වේද

ස්ථාපිත කර ඇත්තේ කුමක්ද යන්න නොව, සැබවින්ම සක්‍රීයව ඇත්තේ කුමක්දැයි සොයා ගන්න. නවීන බෙදාහැරීමක විසඳන්නන් කිහිපයක් තිබිය හැකි අතර, loopback අතුරුමුහුණතේ 53 වරාය තබා ගන්නා එක පිළිතුරු දෙයි:

systemctl status systemd-resolved --no-pager
resolvectl status
ss -lunp | grep ':53'

තත්ත්ව ප්‍රතිදානය සෑම සබැඳියකම DNS සේවාදායක සහ මාර්ගගත කිරීමේ වසම් නම් කරයි, එය split DNS සඳහා ඔබට අවශ්‍ය සිතියමයි. අභ්‍යන්තර නාම අභ්‍යන්තර සේවාදායකයකට සහ අනෙක් සියල්ල පොදු එකකට යා යුතු නම්, එම ප්‍රතිපත්තිය සෑම සබැඳියකම වසම්වල ජීවත් වේ, එය ගොනුවේ ස්ථිතික nameserver ලැයිස්තුවකට පැතලි කිරීම එම වෙනස නිහඬව අහිමි කරයි.

NetworkManager හිම කොන්ෆිගරේෂන් විසින් මෙම backend වලින් කුමක් භාවිත කරන්නේද යන්න තීරණය කරයි. ප්‍රධාන කොන්ෆිගරේෂන් ගොනුවේ එහි dns= සැකසුම එහි අභ්‍යන්තර විසඳන්නා, dnsmasq, systemd-resolved සහ none අතර තෝරයි, සහ බෙදාහැරීම ඔබ වෙනුවට තෝරා තිබිය හැකිය. මෙම සත්කාරකයේ “DNS අලුත්වැඩියා කිරීම” යන්නෙන් අදහස් කුමක්ද යන්න තීරණය කිරීමට පෙර එම සැකසුම කියවන්න.

පරීක්ෂණය 3: VPN සේවාදායකයට ලිවීමට අවසර ඇත්තේ කුමක්ද

ගැටුම සාමාන්‍යයෙන් ජීවත් වන්නේ මෙහිය. විසඳන්නාගේ ගොනුව සෘජුවම නැවත ලියන VPN සේවාදායකය එයද නඩත්තු කරන ඕනෑම සේවාවක් සමඟ සටන් කරනු ඇත, සහ පරාජය වන්නේ පළමුව ධාවනය වන්නාය. නවීන OpenVPN නිකුතු ගොනුව නැවත ලිවීම වෙනුවට DNS සැකසුම් systemd-resolved වෙත භාර දිය හැක, එය ඔබට අවශ්‍ය සහයෝගී හැසිරීමයි; පැරණි ස්ක්‍රිප්ට් සහ අතින් ලියූ කොක්ක බොහෝ විට පැරණි සහායක මෙවලමක් අමතයි නැතහොත් ගොනුව උඩින් ලියයි.

WireGuard හි තත්ත්වය හැඩයෙන් සමානය: අතුරුමුහුණත් කොන්ෆිගරේෂන්ම DNS කළමනාකරණය නොකරයි, ඒ වටා ඇති මෙවලම් කරයි, විසඳන්නා සහායකයක් හෝ resolved ඒකාබද්ධතාවයක් හරහා. එවැනි සහායක දෙකක් ස්ථාපිත නම්, දෙකම සම්බන්ධ වන විට තම ලෝක දැක්ම ක්‍රියාත්මක කිරීමට උත්සාහ කරනු ඇත.

අනුමාන කිරීම වෙනුවට සේවාදායකයේ up සහ down කොක්ක කියවන්න. /etc/openvpn/up.sh හෝ සමාන නාමාවලියක shell පේළි කිහිපයක් වෙනත් ආකාරයකින් අහඹු ලෙස පෙනෙන හැසිරීම පැහැදිලි කරයි, එය සේවාදායකය තරඟ කිරීම වෙනුවට සහයෝගයෙන් ක්‍රියා කිරීමට යොදන ස්ථානයද එයමය.

පරීක්ෂණය 4: එය හිමිකරු වෙත නිවැරදි කරන්න, ගොනුවේ නොවේ

හිමිකරු කවුදැයි දැනගත් පසු, එම හිමිකරු සහාය දක්වන අතුරුමුහුණත හරහා DNS වින්‍යාස කරන්න. systemd-resolved සඳහා එයින් අදහස් වන්නේ ස්ථිතික ගොනුවක් වෙනුවට සෑම සබැඳියකම සැකසුම් සහ මාර්ගගත කිරීමේ වසම්; NetworkManager සඳහා සම්බන්ධතා පැතිකඩෙහි DNS සැකසුම් සහ තෝරාගත් backend; resolvconf ඒකාබද්ධතාවයක් භාවිත කරන බෙදාහැරීමක් සඳහා එම සහායකය හරහා ලිවීමයි.

ගොනුව වෙනස් නොවන එකක් නොකරන්න. වෙනස් නොවන ගුණාංගය නීත්‍යානුකූල DHCP අලුත් කිරීම් සහ VPN යාවත්කාලීන ඔබ සටන් කළ ඒවා සමඟම නවත්වයි, සහ ඊළඟ පැකේජ උත්ශ්‍රේණි කිරීම හෝ නැවත සම්බන්ධ වීම වින්‍යාසයෙන් කිසිවෙකුට පැහැදිලි කළ නොහැකි අසාර්ථකත්වයක් ඇති කරන තත්ත්වයක පද්ධතිය තබයි. එය හිමිකාරිත්ව ගැටුම සඟවයි, එය ඔබ විසඳීමට උත්සාහ කළ දෙයමයි.

සංරචක දෙකක් සැබවින්ම සමගාමීව පැවතිය යුතු තැන, ඔවුන්ට වෙනස් කාර්යයන් දෙන්න. ජාල කළමනාකරුට අතුරුමුහුණත් මට්ටමේ වින්‍යාසය හිමි කර දෙන්න, VPN සේවාදායකයට එම ඒකාබද්ධතාවය හරහා සෑම සබැඳියකම DNS සහ වසම් දායක කරන්නට ඉඩ දෙන්න, සහ ගොනුව සෘජුවම ලියන තුන්වන ස්ක්‍රිප්ටය ඉවත් කරන්න. systemd-resolved හි ලේඛනය එය සහාය දක්වන මාදිලි සහ ඒවායින් එකක් /etc/resolv.conf හි පෙන්වන දේ විස්තර කරයි. ඔබ රඳවා ගත යුතු ප්‍රතිපත්ති ප්‍රමාණයට ගැළපෙන මාදිලිය තෝරන්න. split DNS වැදගත් නම්, සෑම සබැඳියකම වසම් සහිත stub සැකැස්ම එය ආරක්ෂා කරයි, upstream සේවාදායක ගොනුවට පිටපත් කරන මාදිලිය එය නිහඬව පැතලි කරයි.

නැවත සම්බන්ධ වීමෙන් පසු සත්‍යාපනය කරන්න, සංස්කරණයෙන් පසු නොවේ

ඔබේ වෙනසට පසුව වහාම නිවැරදි ලෙස පෙනෙන ගොනුවක් කිසිවක් ඔප්පු නොකරයි, මක්නිසාද ඊළඟ සිදුවීම තවම සිදුවී නැත. එය කලින් බිඳ දැමූ අනුපිළිවෙල ක්‍රියාත්මක කරන්න: උමං මාර්ගය පහළට දමා නැවත ඔසවන්න, DHCP බද්ද අලුත් කරන්න හෝ අතුරුමුහුණත මාරු කරන්න, පසුව එම අගයන් නැවත කියවන්න.

resolvectl query build.corp.example
resolvectl query example.com
resolvectl status | head -40

පසුව වැදගත් වෙනස තහවුරු කරන්න: අභ්‍යන්තර නාමය අභ්‍යන්තර සේවාදායකය හරහා විසඳෙන අතර පොදු නාමය තවමත් ක්‍රියා කරයි. සියල්ල අභ්‍යන්තර සේවාදායකයට යවන වින්‍යාසය කෙනෙක් උමං මාර්ගයෙන් අන්තර්ජාලයට ළඟා වීමට උත්සාහ කරන තෙක් හොඳින් පෙනේ, සහ සියල්ල පොදු එකට යවන වින්‍යාසය අභ්‍යන්තර නාම කාන්දු කරයි.

යෙදවීම් සටහන්වල හිමිකරු, backend සහ සිම්බොලික් සබැඳි මාදිලිය සටහන් කරන්න. එම එකම ඡේදය අනාගත පැකේජ උත්ශ්‍රේණි කිරීමක් සිදුවීමකින් සමාලෝචන අයිතමයක් බවට පත් කරයි, සහ ඊළඟ පුද්ගලයාට chattr විධානයෙන් එම ගැටුම නැවත සොයා ගැනීම වළක්වයි.

අදාළ ලිපි