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

Hosts යනු දේශීය අභිබවා යාමකි, කලාප යාවත්කාලීනයක් නොවේ

ගොනුව යනු නම් සේවා පුස්තකාල DNS සේවාදායකයෙන් විමසීමට පෙර හෝ ඒ වෙනුවට බලන සිතියම්කරණ ලැයිස්තුවකි. 10.40.0.20 build.corp.example වැනි පේළියක් එම එකම යන්ත්‍රයේ යෙදුම් ගන්නා නිගමනය වෙනස් කරයි. එය වාර්තාවක් සාදන්නේ නැත, උමං මාර්ගය හරහා ගමන් නොකරයි, සහ උමං මාර්ගය යොමු වන DNS සේවාදායකයට එය පවතින බව කිසිදු අදහසක් නැත.

එබැවින් අසාර්ථකත්වය අසමමිතික ය. ඔබේ සේවාලාභියා ගොනුවෙන් පිළිතුරක් ලබා ගනී. තවත් සේවාලාභියෙක් VPN හි DNS සේවාදායකයෙන් විමසන අතර, එය කිසිවක් ආපසු නොදෙයි, යෙදුම නම නොපවතින බව වාර්තා කරයි. යන්ත්‍ර දෙකම නිවැරදිව හැසිරේ; එකකට පමණක් අනෙකා කිසිදා නොදුටු අභිබවා යාමක් ඇත.

විධාන දෙකක්, වෙනස් සංරචක දෙකක්

මෙම තර්කය නැවැත්වීමට වේගවත්ම ක්‍රමය වන්නේ වෙනස විධාන දෙකකින් දෘශ්‍යමාන කිරීමයි, දෙකම hosts සටහන ඇති සේවාලාභියා මත ක්‍රියාත්මක වේ:

getent ahosts build.corp.example
dig @10.40.0.53 build.corp.example A

පළමුවැන්න පද්ධතියේම සෙවුම් මාර්ගයෙන් විමසයි, එය සාමාන්‍ය glibc පද්ධතියක DNS ට පෙර දේශීය ගොනු කියවයි. දෙවැන්න එම ලිපිනයේ සේවාදායකයට සෘජුවම DNS විමසුමක් යවයි, දේශීය ගොනු කිසිසේත් නොබලයි. පළමුවැන්න ඔබේ සටහන ආපසු දෙන විට දෙවැන්න NXDOMAIN ආපසු දුන් විට, වාර්තාව DNS හි නොපවතින බවත් ඔබේ යන්ත්‍රය දේශීය අභිබවා යාමකින් පිළිතුරු දෙන බවත් ඔබ ඔප්පු කර ඇත.

අනුපිළිවෙල වින්‍යාසගත කළ හැකි අතර, යම් බෙදාහැරීමක් ගැන කිසිදු නිගමනයකට ඒමට පෙර එය පරීක්ෂා කිරීම වටී. /etc/nsswitch.conf හි hosts: පේළිය බලන්න; hosts: files dns පළමුව ගොනු බලයි. අනුපිළිවෙල වෙනස් කිරීමට පමණක් එම උදාහරණය ක්‍රියාකාරී වින්‍යාසයක් මත පිටපත් නොකරන්න, මන්ද සැබෑ පද්ධති බොහෝ විට උදාහරණයේ නොමැති අමතර මූලාශ්‍ර සහ කොන්දේසි සහිත සේවා සටහන් ලැයිස්තුගත කරයි.

systemd-resolved පරීක්ෂණය බොඳ කරයි

systemd-resolved භාවිතා කරන පද්ධතියක දේශීය stub ද hosts දත්ත සමුදායෙන් නම් සපයයි. එබැවින් 127.0.0.53 වෙත විමසුම දුරස්ථ සේවාදායකයේ ස්වාධීන පරීක්ෂණයක් නොවේ, එය DNS විමසුමක් ලෙස පෙනී එසේ හැසිරුණත්. විසඳන්නා දන්නා දේ සහ කුමන සේවාදායකයන්ගෙන් විමසන්නේද යන්න ඔබට මෙයින් තහවුරු කළ හැකිය:

resolvectl query build.corp.example
resolvectl status

status ප්‍රතිදානය එක් එක් සබැඳිය සඳහා DNS සේවාදායක නම් කරයි, එසේ ඔබ VPN සබැඳියට විසඳන්නෙක් ලැබුණාදැයි දැන ගනී. එම ප්‍රශ්නය hosts සටහනින් වෙන් වන අතර පුද්ගලික නමක් එක් අයෙකුට නොව සෑම පරිශීලකයාටම අසාර්ථක වන විට ඇසිය යුතු ප්‍රශ්නය එයයි.

යෙදුම් තවත් ස්ථරයක් එකතු කළ හැකිය. තමන්ගේම DNS-over-HTTPS සැකසුමක් ඇති බ්‍රවුසරයක්, තමන්ගේම විසඳන්නා වින්‍යාසයක් ඇති බහාලුමක්, හෝ ක්‍රියාවලියේ මුළු ආයු කාලය තුළ සෙවුම් හැඹිලිගත කරන ධාවන පරිසරයක් එක් එක් ස්වයංක්‍රීයව පද්ධතියට වඩා වෙනස් ලෙස පිළිතුරු දිය හැකිය. එක් විධානයක් යන්ත්‍රයේ සෑම වැඩසටහනක්ම විස්තර කරයි යැයි උපකල්පනය නොකර ඔබට වැදගත් යෙදුම පරීක්ෂා කරන්න.

VPN හරහා නමක් සැබවින්ම බෙදා ගන්නේ කුමක්ද

පුද්ගලික නමක් සැමට ක්‍රියා කළ යුතු නම්, සැමගේ විසඳන්නාට ළඟා විය හැකි හිමිකරුවෙක් අවශ්‍යයි. පිරිසිදු පිළිතුර වන්නේ වාර්තාව කළමනාකරණය කළ කලාපයක ප්‍රකාශයට පත් කර එම කලාපය VPN හි අපේක්ෂිත DNS මාර්ගය හරහා විසඳිය හැකි කිරීමයි. එවිට වාර්තාවට එක් සත්‍ය මූලාශ්‍රයක්, විගණන මාර්ගයක් සහ ජීවන චක්‍රයක් ඇත, කිසිවෙකුට කුමන ලැප්ටොප් එකේ දේශීය අභිබවා යාමක් ඇත්දැයි මතක තබා ගැනීමට අවශ්‍ය නැත.

hosts ගොනු බෙදාහැරීම වලංගු විකල්පයකි, එය නම් සේවාවක් නොව අන්ත ලක්ෂ්‍ය කළමනාකරණයකි. ඔබ එය තෝරා ගන්නේ නම්, ගොනුව බලඇණිය කළමනාකරණය කරන දෙයක් විසින් යෙදවීම, අනුවාද කිරීම සහ ඉවත් කිරීම කළ යුතු අතර, නිර්මාණයේදී එය එසේම විස්තර කළ යුතුය. “VPN එය හසුරුවයි” යනු එම ක්‍රියාවලියේ විස්තරයක් නොවේ.

ගතිශීලී DNS ලියාපදිංචිය තෙවන යාන්ත්‍රණයයි, එහිම අවසර, යාවත්කාලීන සත්‍යාපනය සහ වාර්තා ආයු කාලය ඇත. එය hosts සටහනකින් එන්නේ නැත, සේවාලාභියා සරලව සම්බන්ධ වීමෙන්ද එන්නේ නැත, සේවාදායකය සහ සේවාලාභියා දෙදෙනාම ඒ සඳහා වින්‍යාසගත කර නොමැති නම්. තමන්ම දිස්වන වාර්තාවක් යනු යමෙක් ආරක්ෂිත යාවත්කාලීන සක්‍රීය කළ බවටත් සේවාලාභියෙක් තමන්ම ලියාපදිංචි වන බවටත් සංඥාවකි, එම වින්‍යාසය දෝෂ නිරාකරණ ත්‍රෙඩ් එකක නොව නිර්මාණ වාර්තාවේ තිබිය යුතුය. එම සැකසුමේ හිමිකරු කවුරුන්දැයි කිසිවෙකුට කිව නොහැකි නම්, ස්වයංක්‍රීය වාර්තාව තහවුරු නොකළ ලෙස සලකා කළමනාකරණය කළ කලාපය සත්‍ය මූලාශ්‍රය ලෙස තබා ගන්න.

විසඳන ලද නමක් මාර්ගයක් නොවේ

නම් විසඳීම සහ ළඟා වීමේ හැකියාව වෙනස් දේවල්, සහ පැරණි දේශීය සිතියම්කරණය ඒවා ව්‍යාකූල කිරීමේ සම්භාව්‍ය ක්‍රමයයි. ගෙවී ගිය ලිපිනයකට යොමු වන hosts සටහනක් DNS නිවැරදි කිරීමෙන් බොහෝ කලකට පසුවත් පැරණි සත්කාරකය තෝරා ගනිමින් සිටිනු ඇත, ලක්ෂණය හොඳින් විසඳෙන නමක් මත භෞතික මාර්ගගත කිරීමේ අසාර්ථකත්වයක් ලෙස පෙනේ.

එබැවින් වාර්තාව “නම විසඳෙන නමුත් සේවාවට ළඟා විය නොහැක” යැයි පවසන විට, පද්ධති සෙවුම VPN හි DNS සේවාදායකයට කරන පැහැදිලි විමසුමක් සමඟ සසඳන්න, පසුව ඔබට ලැබුණු ලිපිනය සේවාව සැබවින්ම භාවිතා කරන ලිපිනය සමඟ පරීක්ෂා කරන්න. systemd-resolved යොමුව එය බලන දේශීය මූලාශ්‍ර ලේඛනගත කරයි, එම සංසන්දනයට අවශ්‍ය සිතියම එයයි.

පසුව අභිබවා යාම එහි හිමිකරු හරහා නිවැරදි කරන්න. ඔබේම hosts ගොනුවෙන් පේළියක් ඉවත් කිරීම යෙදවුම් ස්ක්‍රිප්ටයකින් එම පේළියම ලැබූ එම දොළොස් ලැප්ටොප් සඳහා කිසිවක් නොකරයි, මිනිසුන්ට සැබවින්ම ඇති මෙම ගැටලුවේ අනුවාදය එයයි.

අදාළ ලිපි