ඔබ ටනලය සම්බන්ධ කර, පුද්ගලික උපකරණ පුවරුවක් විවෘත කරන විට, නම ඔබ කිසිදා නොදුටු ලිපිනයකට විසඳේ. නැතහොත් ප්‍රතිවිරුද්ධ දේ සිදුවේ: බ්‍රව්සරය දිගටම වැඩ කරන අතර, විධාන රේඛා මෙවලමක් හදිසියේම කිසිවක් විසඳන්නේ නැත. ප්‍රතිඵල දෙකම එකම වෙනසකින් පැමිණේ, සහ මිනිසුන් සාමාන්‍යයෙන් මෙය VPN "තමන්ගේම DNS භාවිත කරයි" යන එක් වාක්‍යයකින් පැහැදිලි කරයි, එය දෝෂ නිරාකරණයට හෝ තහවුරු කිරීමට ප්‍රමාණවත් තරම් නිවැරදි නොවේ. එම වාක්‍යයේ ප්‍රශ්න දෙකක් සැඟවී ඇත: මෙම පැතිකඩ කුමන විමසුම් භාරගත යුතුද, සහ ඔබේ යන්ත්‍රය ඒවා සැබවින්ම එයට දුන් විසඳනය වෙත යැව්වාද? ඒවා වෙන් කර තබා ගැනීම මුළු ක්‍රමයයි, මන්ද ඒවා මිශ්‍ර කරන පරීක්ෂණය දිශා දෙකෙහිම විශ්වාසවන්ත වැරදි පිළිතුරක් ලබා දෙයි.

පැතිකඩක් කිසිසේත් විසඳනයක් සපයන්නේ ඇයි

ටනලය තුළ, දුර කෙළවර පිටුපස ඇති නම් සාමාන්‍යයෙන් එම ජාලයේ පමණක් පවතින ලිපිනවලට විසඳේ. corp.internal වැනි පුද්ගලික කලාපයකට පොදු පැවරීමක් නැත, එබැවින් එයට පිළිතුරු දෙන විසඳනය ටනලය තුළින් ළඟා විය හැකි විය යුතුය. එම ක්‍රියාවලියම දෙවන අරමුණකට ද උපකාරී වේ: විමසුම් වෙනත් ආකාරයකින් ඔබේ ISP හරහා පිටව යන විට, දුර පසෙහි විසඳනය විමසුම කේතාංකිත මාර්ගය තුළ තබා ගනී. එබැවින් DNS සේවාදායක ලිපිනය සම්බන්ධතාවයේ ප්‍රතිපත්තියේ කොටසක් ලෙස පැමිණේ, යන්ත්‍රය සඳහා එක් වරක් තෝරාගත් ගෝලීය සැකසුමක් ලෙස නොවේ.

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

පිළිතුරු සසඳන්නට පෙර ආකෘති දෙක සසඳන්න

සම්පූර්ණ ටනලය සහ බෙදුණු DNS විරුද්ධ අපේක්ෂා ඇති කරයි, සහ දෙකම දෝෂයක් නොවේ. සම්පූර්ණ ටනලය යටතේ සෑම විමසුමක්ම සැපයුම්කරු හෝ ආයතනික විසඳනය වෙත යා හැකිය, එබැවින් සම්බන්ධ වීමෙන් පසු පොදු නම් වෙනස් ලෙස පිළිතුරු දීම අපේක්ෂිතය. බෙදුණු DNS යටතේ ලැයිස්තුගත වසම් පමණක් පුද්ගලික විසඳනය වෙත යන අතර අනෙක් සියල්ල දේශීයව රැඳේ; Windows හි වසම් ලැයිස්තුව Name Resolution Policy Table හි, macOS හි DNS සැකසුම්වල ගැළපෙන වසම්වල, සහ systemd-resolved සත්කාරකයේ සෑම සබැඳියකම රවුටින් වසම්වල පවතී.

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

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

එක් විචල්‍යයක් පමණක් සමඟ මූල රේඛාවක් සටහන් කරන්න

ටනලය වෙනස් කරන්න. එම පියවරේදීම නම, මෙවලම හෝ සෙවුම් උපසර්ගය ද වෙනස් නොකරන්න. විමසීමට අවසර ඇති නමක් තෝරන්න, කුමන යෙදුමක් භාවිත කළාද සටහන් කරන්න, සහ ආපසු ආ ලිපිනය හෝ නිශ්චිත දෝෂය ලියන්න. Windows හි Get-DnsClientServerAddress -AddressFamily IPv4 සෑම අඩප්ටරයකම සේවාදායක මුද්‍රණය කරන අතර Get-DnsClientNrptPolicy ප්‍රතිපත්ති සටහන් මුද්‍රණය කරයි; systemd-resolved සහිත Linux හි resolvectl status සෑම සබැඳියකම DNS සේවාදායක සහ රවුටින් වසම් පෙන්වයි; macOS හි scutil --dns පද්ධතිය සැබවින්ම අනුගමනය කරන විසඳන අනුපිළිවෙල මුද්‍රණය කරයි.

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

පැහැදිලි විමසුමක් සහ යෙදුම් සෙවුමක් වෙනස් පරීක්ෂණ වේ

එක් නිශ්චිත සේවාදායකයකින්, nslookup name 10.20.0.1 හෝ dig @10.20.0.1 name සමඟ ඇසීම එක් දෙයක් පමණක් සනාථ කරයි: ඔබ නම් කළ සේවාදායකය එයට ළඟා විය හැකි විට පිළිතුරු දෙන බව. එය තේරීම් තර්කය සම්පූර්ණයෙන් මඟ හරියි, එබැවින් පද්ධතිය මෙම නම සඳහා එම සේවාදායකය තෝරා ගනීද යන්න එය කිව නොහැක. පවරන ලද විසඳනය ළඟා විය හැකිද යන්න පරීක්ෂා කිරීමට එය භාවිත කරන්න, සහ ප්‍රතිපත්තිය පරීක්ෂා කිරීමට එය භාවිත නොකරන්න.

දේශීය විසඳනය හරහා කරන සෙවුමක් තේරීම සැබවින්ම භාවිත කරයි. resolvectl query name එම රවුටින්-වසම් නීති ඔස්සේ ගොස් කුමන ප්‍රොටෝකෝලය පිළිතුරු දුන්නේද යන්න වාර්තා කරයි, Windows හි Resolve-DnsName ප්‍රතිපත්ති වගුව සහ සේවාලාභී හැඹිලිය හරහා යයි, සහ scutil --dns සෙවුමක් අනුගමනය කරන අනුපිළිවෙල පෙන්වයි. වර්ග දෙකම ක්‍රියාත්මක කර ඒවා ඔබේ සටහන්වල වෙන වෙනම තීරුවල තබා ගන්න. සාර්ථක පැහැදිලි විමසුමක් අසල අසාර්ථක යෙදුම් සෙවුමක් තිබීම රවුටින් හෝ තේරීම් ගැටලුවකි, වැඩ කිරීම ප්‍රතික්ෂේප කරන විසඳනයක් නොවේ.

හැඹිලිය ඔබ සහ පිළිතුර අතර සිටී. මෙහෙයුම් පද්ධතිය, දේශීය stub විසඳනය, බ්‍රව්සරය සහ සෘණ හැඹිලිය සියල්ලම ප්‍රතිඵල තබා ගනී, එබැවින් එක් පැකට්ටුවක්වත් යන්ත්‍රයෙන් පිටව නොගොස් සෙවුමක් සාර්ථක විය හැකිය. කිසිවක් හිස් කිරීමට පෙර ප්‍රතිඵලය සටහන් කරන්න: ipconfig /flushdns, resolvectl flush-caches හෝ macOS හි sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder. මෙම අවස්ථාවේදී පුළුල් ජාල නැවත සැකසීම මඟ හරින්න, මන්ද එය ඔබ තවම එකතු කරන සාක්ෂි විනාශ කරයි.

මෙම වෙනසෙන් අදහස් වන්නේ කුමක්ද

ඔබ සටහන් කළ පේළි දෙක සසඳා, එක් සැකසුමක්වත් ස්පර්ශ කිරීමට පෙර වෙනස වර්ගීකරණය කරන්න.

Observation after connectMost likely causeNext step
Answer moves to a private address rangeExpected under split DNS or a private zoneConfirm the suffix is in the effective policy, then test the service
Lookup times out while connected, works after disconnectThe assigned resolver has no route from this machineProbe it with an explicit query, then re-read the policy
Internal name fails, public names workWrong namespace or a suffix missing from the policyQuery the fully qualified name and check the domain list per platform
Internal name returns a public addressSplit DNS not applied; a public resolver answeredCheck browser secure DNS first, then the per-link domain list

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

මූල රේඛාව නැවත පිහිටුවා තහවුරු කරන්න

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

මෙම ලැයිස්තුව එක් වරක්, පිළිවෙලට කරන්න. ඕනෑම ප්‍රතිඵලයක් විනිශ්චය කිරීමට පෙර පැතිකඩ කුමන ආකෘතිය ක්‍රියාත්මක කරන්නේද යන්න තීරණය කරන්න. ධාවන දෙකෙහිම නම, මෙවලම සහ උපසර්ගය ස්ථිරව තබා ගන්න. පැහැදිලි විමසුම යෙදුම් සෙවුමෙන් වෙන් කරන්න. පිළිතුර පමණක් නොව, ඵලදායී ප්‍රතිපත්තිය කියවන්න. සසඳනය ලියා අවසන් වූ පසු හැඹිලි අවසානයේ හිස් කරන්න. සැබෑ යෙදුම සමඟ තහවුරු කර, පසුව එක් වරක් නැවත අරඹා විසන්ධි තත්ත්වය තවමත් පිරිසිදු බව තහවුරු කරන්න.

අදාළ ලිපි