VPN DNS වැඩ කරයි, නමුත් .local නම් තවමත් අසාර්ථක වේ: ඒවා විසඳන්නේ කවුද?

එකම VPN එකේ යන්ත්ර දෙකක්, එකම සත්කාරක නම, සහ ඒවායින් එකක් පමණක් එය විසඳයි: වෙනස සාමාන්‍යයෙන් උමඟ නොව, කුමන විසඳන්නා පිළිතුරු දුන්නාද යන්නයි. Linux ඩෙස්ක්ටොප් එකක එම නම නාම සේවා ස්විචය හරහා, systemd-resolved හි stub හරහා, හෝ යෙදුම තමන් සමඟ ගෙන ආ විසඳන්නා හරහා යා හැක, සහ ඒ සෑම එකක්ම එකම උපසර්ගයට තමන්ගේ නියමය යොදයි. නියම වෙනස් වන්නේ උපසර්ගයේදීමයි, මන්ද .local මධ්‍යස්ථ ලේබලයක් නොවේ. යමක් ක්‍රියාත්මක වන අනුපිළිවෙල වෙනස් කිරීමට පෙර අසාර්ථක වන වැඩසටහන ඇත්තටම ගන්නා මාර්ගය සොයා ගන්න.

විසඳන්නන් දෙකක්, වෙනස් පිළිතුරු දෙකක්

සාම්ප්‍රදායික glibc සොයා බැලීම nsswitch.conf හි hosts: පේළිය හරහා ගොස් එකක් පිළිතුරු දෙන තෙක් සෑම මොඩියුලයකින්ම වාරයකට අසයි. stub ශ්‍රවණය කරන්නා හරහා systemd-resolved සමඟ කතා කරන සේවාදායකය ඒ වෙනුවට එක් ක්‍රියාවලියකින් අසයි, එම ක්‍රියාවලිය සෑම සබැඳියකටම ප්‍රතිපත්තිය සහ තමන්ගේ විශේෂ අවස්ථා යොදයි. තමන්ගේම විසඳන්නා ගෙන එන හෝ එසේ කරන පුස්තකාලයක් සම්බන්ධ කරන යෙදුමකට දෙකම මඟ හැරිය හැක. එබැවින් එක් සත්කාරක නමකට එක් යන්ත්‍රයක කොටස්කරුවන් තිදෙනෙක් සිටිය හැක, සහ ඔවුන්ගෙන් එකෙක් පමණක් VPN අදහස් කළ දේ දනී.

කිසිවක් වෙනස් කිරීමට පෙර හිමිකරු හඳුනා ගන්න, මන්ද තිදෙනාගෙන් එක් අයකුට නිවැරදි කිරීම වෙනස් ය. එකම ඩෙස්ක්ටොප් එකේ බ්‍රවුසරයක් සහ විධාන රේඛා මෙවලමක් නීත්‍යානුකූලව එකඟ නොවිය හැක, එම එකඟ නොවීම සලකුණයි, දෝෂය නොවේ. බ්‍රවුසරය නම විසඳා මෙවලම නොවිසඳන්නේ නම්, ඔබ දෝෂ නිරාකරණය කරන්නේ විසඳන්නාගේ මාර්ගයක් මිස VPN මාර්ගයක් නොවේ. මාර්ගය වෙන වෙනම තහවුරු කරන්න, එවිට මාර්ග ගැටලුවක් නාම සේවා ගැටලුවක් ලෙස වරදවා නොගැනේ. දෙකම එකඟ වූ විට, දෝෂය සත්කාරකයට ඉහළින් ඇති අතර මෙහි විසඳන්නා සැකසුම තවත් සංස්කරණයකට වටින්නේ නැත.

ඔබේ විසඳන්නාගෙන් ඇත්තටම ඇසුවේ කුමන විධානයද

කියවීමට පමණක් වන විධාන දෙකක් සම්බන්ධ ප්‍රශ්නවලට පිළිතුරු දෙයි, ඒවා සසඳා බැලීම සැකසුම කියවීමට වඩා ඉක්මනින් ගැටලුවේ ස්ථානය හඳුනා ගනී. සැබෑ අභ්‍යන්තර නමක් භාවිතා කර ප්‍රතිදානය පෞද්ගලිකව තබා ගන්න, මන්ද අභ්‍යන්තර වාර්තා අභ්‍යන්තරවම රැඳේ. දෙකම අසාර්ථක වැඩසටහන ක්‍රියාත්මක වන එකම සැසියේ ක්‍රියාත්මක කරන්න:

getent ahosts files.corp.local
resolvectl query files.corp.local
resolvectl status

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

ඇයි .local ඔබේ unicast කලාපය මඟ හරින්නේ

systemd-resolved හි යොමුව පවසන්නේ .local න් අවසන් වන බහු ලේබල නම්, mDNS සක්‍රීය විට සාමාන්‍ය unicast DNS වෙත නොව, සාමාන්‍යයෙන් multicast DNS වෙත යන බවයි. RFC 6762 එම නාම අවකාශය link-local multicast සඳහා වෙන් කරයි, එබැවින් ආයතනික කලාපයකට එම උපසර්ගය සඳහා කිසි විටෙක අසන නොනැසී ඇති වාර්තාවක් තිබිය හැක. උමඟට විසඳන්නා කදිම ලෙස මාර්ගගත කර තරඟය පැරදිය හැක. හැඹිලියකින් සාර්ථක ping එකක් දැන් සිදු වූ සොයා බැලීම ගැන කිසිවක් නොකියයි.

ලේඛනගත ව්‍යතිරේකයක් ඇත, එය මෙම අවස්ථා බොහොමයක් විසඳයි: සබැඳියක් එම උපසර්ගය සෙවුම් වසමක් හෝ මාර්ගගත වසමක් ලෙස දැනුම් දෙන විට, ඩීමන් එය unicast මාර්ගයේ තබා multicast විශේෂ අවස්ථාව මඟ හරියි. එය සෑම සබැඳියකටම වන ප්‍රතිපත්තියක් මිස ගෝලීය මනාපයක් නොවේ. එකම VPN සේවාදායකය සහිත යන්ත්‍ර දෙකක් එක් ජාල පැතිකඩක් වසම දැනුම් දෙන විට අනෙක නොදෙන විට වෙනස් ලෙස හැසිරිය හැක, එබැවින් ඔබ සංස්කරණය කළ බව මතක පැතිකඩ නොව, සක්‍රීය පැතිකඩ කියවන්න.

පටු ව්‍යතිරේකය ගෝලීය නැවත සැකසීම පරදවයි

නම වෙනස් කළ නොහැකි දැනට ඇති කලාපයක් සඳහා, විසඳන්නා සහ VPN හිමිකරුවන්ට එම වසම එය ගෙන යන සම්බන්ධතාවයේ දැනුම් දෙන්නට සලස්වන්න. එම එක් උපසර්ගය සඳහා මාර්ගගත වසම් සටහනක් සහ අදහස් කළ සේවාදායක ලිපිනය නම් කළ හිමිකරු සහිත කුඩා වෙනසක් වන අතර, එය අතින් සංස්කරණය කළ ගොනුවක නොව සබැඳිය සමඟ ජීවත් වේ.

සම්බන්ධතාවය බිඳී ගිය පසුවත් එය නොනැසී පවතී, මන්ද සබැඳිය නැවත පැමිණි විට සබැඳි ප්‍රතිපත්තිය නැවත යෙදේ. හවුල් nsswitch.conf සංස්කරණය කිරීම පෙළඹවීම සහ වඩා මිල අධික විකල්පයයි, මන්ද එය යන්ත්‍රයේ සෑම නමකටම සෙවුම් හැසිරීම වෙනස් කරයි, දේශීය සොයා ගැනීම ඇතුළුව. multicast ඩීමන් අක්‍රීය කිරීමද සමාන නොවේ: එය දේශීය හැසිරීම ඉවත් කරයි, නමුත් කිසිදු විසඳන්නෙකුට ආයතනික කලාපය ගැන නොකියයි. සේවාව උරුම නොව නව නම්, එය ඔබේ සංවිධානය පාලනය කරන උප වසමක් යටතේ තබා තරඟය සම්පූර්ණයෙන්ම මඟ හරින්න. නම firmware හි ස්ථිරව හෝ ලේබලයක මුද්‍රණය වී ඇත්නම් පටු ව්‍යතිරේකය තෝරන්න, සහ ඔබ තවමත් සේවාදායකය පාලනය කරන්නේ නම් නව උප වසමක් තෝරන්න.

වෙනසෙන් පසුව ඔප්පු කළ යුත්තේ කුමක්ද

නිවැරදි කිරීම යෙදුමේම සෙවුමෙන් ඔප්පු කරන්න, පරීක්ෂාව සඳහා ස්ථාපනය කළ මෙවලමකින් නොව, එය වෙනුවට පිළිතුරු දිය හැකි ඕනෑම හැඹිලියක් හිස් කරන්න. පසුව විසඳන්නාගේ මාර්ගය සහ පිළිතුරු දුන් සබැඳිය තහවුරු කරන්න. අවසානයේ දේශීය සොයා ගැනීම වෙනසට පෙර මෙන් හැසිරෙන්නේ දැයි පරීක්ෂා කරන්න, මන්ද දිස්වීම නතර වන මුද්‍රණ යන්ත්‍රය එයයි මිනිසුන් අවසානයේ දකින කොටස. මෙම විධාන තුන නම, මාර්ගය සහ TLS අනන්‍යතාව එම අනුපිළිවෙලින්ම පරීක්ෂා කරයි:

getent ahosts files.corp.local
resolvectl query files.corp.local
curl -sv --max-time 5 https://files.corp.local/ 2>&1 | head -n 20

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