Windows සේවාදායකයකට වැඩ කරන උමං මාර්ගයක් තිබිය හැක, ආයතනික විසඳන්නා රැගෙන යා හැක, එහෙත් අභ්‍යන්තර නාම නිවසේ රවුටරයට යැවිය හැක. කුමන සේවාදායකය පිළිතුරු දෙනවාද යන්න විවිධ ක්‍රම තුනක් තීරණය කරයි, ඒවා විවිධ ආකාරයෙන් අසාර්ථක වේ. තුනම නිවැරදි කිරීම අවශ්‍ය නැත: රෝග ලක්ෂණය කියන්නේ කුමක් ක්‍රියාත්මකද කියාය. පහත තීරණ ගස මිනිත්තු කිහිපයක් ගන්නවා, මෙට්‍රික් වෙනස, රෙජිස්ට්‍රි ප්‍රතිසංවිධානය සහ NRPT රීතිය එකට එන විට කවුරුත් කුමක් කළාද නොදන්නා සුලබ ප්‍රතිඵලය වළක්වයි.

ක්‍රම තුනක් තීරණය කරයි, සාමාන්‍යයෙන් එකක් වැරදියි

අතුරුමුහුණත් මෙට්‍රික් ලබා දී ඇති ලිපින පවුලක් සඳහා අනුවර්තක පිළිවෙලට තබයි. Tcpip\Linkage යටතේ ඇති බැඳීම් අනුපිළිවෙල පැරණි කේත මාර්ග තවම බලන යන්ත්‍ර මට්ටමේ අතුරුමුහුණත් හඳුනා ගන්නන්ගේ ලැයිස්තුවකි. නාම විශ්ලේෂණ ප්‍රතිපත්ති වගුව (NRPT) නාම අවකාශයක් නිශ්චිත සේවාදායකවලට බඳියි, පසුබැස්ම ලැයිස්තුව කෙටි නාමයක් කිසිසේත් දිගු වේද යන්න තීරණය කරයි. ඒවා ස්වායත්ත බැවින් VPN අනුවර්තකයේ නිවැරදි විසඳන්නා වෙනත් තැනක පැරණි මනාපයකට පරාජය වේ.

What you seeMechanism to checkFirst command
Every name is slow, public names sometimes wrongGlobal adapter order: metric, then LinkageGet-NetIPInterface
Internal names resolve to a public addressThe query left through the home resolver, not the tunnelResolve-DnsName intranet.corp.example -Type A, then the same query with -Server 10.20.0.10
Only corp.example names fail, public names fineNamespace binding: NRPT or suffixGet-DnsClientNrptRule
Short name fails, fully qualified name worksSuffix list on the adapter, with the corporate suffix ahead of other entries, or pushed by the serverGet-DnsClientGlobalSetting
Works, then breaks after a reconnectRuntime setting that was never persistedGet-VpnConnection for the stored profile, then Get-NetIPInterface again after a reconnect

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

තීරණය එක: තල්ලු කළ විසඳන්නාට කිසිසේත් පිළිතුරු දිය හැකිද?

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

Resolve-DnsName intranet.corp.example -Server 10.20.0.10 -Type A
Resolve-DnsName intranet.corp.example -Type A

පළමුවැන්න සාර්ථක වී දෙවැන්න අසාර්ථක නම්, විසඳන්නා ප්‍රවේශ විය හැකි අතර Windows වැරදි ලෙස තෝරයි; පහත නාම අවකාශ සහ අනුපිළිවෙල තීරණ වෙත යන්න. පළමුවැන්නද අසාර්ථක නම් සේවාදායකයේ කිසිවක් උදව් නොකරයි: UDP සහ TCP 53 උමං මාර්ගය හරහා සේවාදායකයට ළඟා වේද, සේවාදායකයේ සත්කාරක ගිනිපවුර තටාකය ඉවත නොදමයිද, සේවාදායකයේම යොමු කරන්නන් සුවපත්ද පරීක්ෂා කරන්න.

මෙම අත්තේ නවතින්න. ළඟා විය නොහැකි විසඳන්නෙකුට NRPT රීතියක් යෙදීම එමම අසාර්ථකත්වය තවත් ආපසු හැරවිය යුතු වින්‍යාසයක් සමඟ ලබා දෙන අතර සැබෑ දෝෂය අධිකාරී ලෙස පෙනෙන රීතියක් පිටුපස සඟවයි.

තීරණය දෙක: එක් නාම අවකාශයක්ද නැතහොත් සෑම ප්‍රශ්නයක්ද?

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

සෑම ලිපින පවුලකටම, අතුරුමුහුණත් දෙකේම මෙට්‍රික් සකසා, පසුව අනුපිළිවෙල තහවුරු කරන්න:

Get-NetIPInterface | Select-Object ifIndex, InterfaceAlias, AddressFamily, InterfaceMetric
Set-NetIPInterface -InterfaceIndex 11 -InterfaceMetric 1 -AddressFamily IPv4
Set-NetIPInterface -InterfaceIndex 11 -InterfaceMetric 1 -AddressFamily IPv6

ඉහත පේළියේ උමං අනුවර්තකයේ ifIndex සමඟ 11 වෙනස් කරන්න; 11 LAN අනුවර්තකය නම්, එම විධානයම වැරදි මාර්ගය පහත හෙළයි. ඒ වෙනුවට LAN අනුවර්තකය ඔසවා අනෙක් පැත්තෙන් එම අනුපිළිවෙලටම ළඟා වේ: netsh int ip set interface interface="Ethernet" metric=15, දෙවන පවුලට netsh int ipv6 set interface interface="Ethernet" metric=15, මන්ද int ip IPv4 ට පමණක් ස්පර්ශ කරයි.

බැඳීම් අනුපිළිවෙල පළමු පියවර නොව අවසාන උපායයි. HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Linkage උපාංග හඳුනා ගන්නන්ගේ Bind ලැයිස්තුවක් රඳවා ගනී, උමං හඳුනා ගන්නා ඉදිරියට ගෙන ඒම ඇත්තෙන්ම කුමන අනුවර්තකය පළමුව ඇසෙන්නේද යන්න වෙනස් කරයි, නමුත් එය නාම අවකාශය අනුව විෂය පථයක් නොමැති යන්ත්‍ර මට්ටමේ ලේඛන අගයකි. සංස්කරණයට පෙර එය අපනයනය කර පසුව උමං මාර්ගය නැවත සම්බන්ධ කරන්න, එවිට අනුපිළිවෙල සේවාදායකය අපේක්ෂා කරන තත්වයේ යෙදේ.

එක් නාම අවකාශයකට, පටු මෙවලම තෝරන්න:

Add-DnsClientNrptRule -Namespace ".corp.example" -NameServers 10.20.0.10
Get-DnsClientNrptRule | Select-Object Namespace, NameServers

තීරණය තුන: නැවත සම්බන්ධ වීමෙන් පසු නිවැරදි කිරීම ඉතිරි වේද?

මීළඟ ඩයල්-අප් නැවත සම්බන්ධතාවය දක්වා ක්‍රියා කරන මෙට්‍රික් කිසිදා සුරකිනු නොලැබීය. L2TP/IPsec සහ අනෙක් සම්බන්ධතා පැතිකඩ සම්බන්ධතාවය ආරම්භ වන විට නැවත සාදනු ලැබේ, එබැවින් සුරකින ලද අගය දුරකථන පොත් සටහනේ IpInterfaceMetric ලෙස ජීවත් වේ, සක්‍රීය අතුරුමුහුණතේ පමණක් නොවේ. සමහර පරිසරයන් එම ක්ෂේත්‍රය හරියටම මේ හේතුව නිසා ස්ක්‍රිප්ට් කරයි; අනෙක් ඒවා කළමනාකරණ ප්‍රතිපත්තියකින් මනාපය තල්ලු කර අන්ත ලක්ෂ්‍යය නිදානයේ තබයි.

හැඹිලිය සහ ලියාපදිංචිය වෙනම ස්ථරයකි. උමං මාර්ගය ඉහළ ගිය පසු මේවා ධාවනය කිරීම පැරණි සටහන් නිවැරදි කර සේවාදායකය නැවත ලියාපදිංචි කරයි, නමුත් කිසිවක් අනුවර්තකය ප්‍රතිසංවිධානය නොකරයි:

ipconfig /registerdns
ipconfig /flushdns

එම ස්ථරයේම අක්‍රීය ස්විචයක් ඇත. භෞතික අනුවර්තකයේ ගතික ලියාපදිංචිය අක්‍රීය කිරීම සේවාදායකය තම VPN පැත්තේ ලිපිනය වැරදි නාමයකින් ප්‍රකාශ කිරීම වළක්වයි, එය ඉහත යාවත්කාලීනයට වඩා වෙනස් අලුත්වැඩියාවකි.

IPv6 තීරණයේ තමන්ගේම පේළියකට සුදුසුය. භෞතික අනුවර්තකයට ගෝලීය IPv6 ලිපිනයක් ඇති අතර උමං මාර්ගය IPv4 පමණක් රැගෙන යයි නම්, Windows නාම විශ්ලේෂණයට උමං රහිත මාර්ගයට මනාප දිය හැක. එම පවුල වෙනම පරීක්ෂා කරන්න, මන්ද IPv4 සඳහා සකසන ලද මෙට්‍රික් ඒ ගැන කිසිවක් නොකියයි:

Get-NetIPInterface -AddressFamily IPv6 | Select-Object ifIndex, InterfaceAlias, InterfaceMetric

LAN අනුවර්තකයේ IPv6 අක්‍රීය කිරීම එම මාර්ගය සහ එය සමඟ ප්‍රොටෝකෝලය ඉවත් කරයි; IPv6 අතුරුමුහුණතේ මෙට්‍රික් වෙනසක් හෝ ආයතනික නාම අවකාශයට NRPT රීතියක් පවුල රඳවා මනාපය නිවැරදි කරයි. එම සබැඳියට IPv6 නොතිබිය යුතුයැයි ඔබ තීරණය නොකළේ නම් පටු එක තෝරන්න.

නම් කළ මූලාශ්‍රය සමඟ සත්‍යාපනය කරන්න, එක් හිමිකරුවෙකු තබා ගන්න

පිටුව පූරණය වේද යන්න පමණක් නොව කුමන මූලාශ්‍රය බලපවත්වයිද යන්න වාර්තා කරන මෙවලම් සමඟ සත්‍යාපනය කරන්න:

ipconfig /all
Get-DnsClientServerAddress -AddressFamily IPv4
Resolve-DnsName fileserver.corp.example -Server 10.20.0.10 -Type A

පසුව පෙරහැරීම තේරීමෙන් වෙන් කරන්න, මන්ද යෙදුමක් තුළින් දෙකම සමානව පෙනේ. OpenVPN හි block-outside-dns අනෙක් අනුවර්තකවල 53 වරාය අවහිර කරයි; එය විසඳන්නෙකු තෝරන්නේ නැත. දැන් සෑම ප්‍රශ්නයක්ම අසාර්ථක නම්, පෙරහනක් එකම ප්‍රවේශ විය හැකි සේවාදායකය අවහිර කරමින් සිටිය හැක; වින්‍යාසගත විසඳන්නා නොසලකා හරින්නේ නම්, අනුපිළිවෙල හෝ නාම අවකාශ රීතිය වැරදිය. දෙකම එකවර වෙනස් කිරීම අවහිර කළ ප්‍රශ්නයක් සහ නොසලකා හළ ප්‍රශ්නයක් වෙන් කර හඳුනාගත නොහැකි කරයි.

DNS ප්‍රතිපත්තියට එක් හිමිකරුවෙකු තබා ගන්න: VPN පැතිකඩ, කළමනාකරණ ප්‍රතිපත්තිය හෝ NRPT රීතිය, ඉන් දෙකක් නොවේ. වැසීමට පෙර:

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

අනුපිළිවෙල අවසන් කරන දෙයක් ලෙස නොව පරිසර තත්වයක් ලෙස සලකන්න. නැවත සම්බන්ධ වීමෙන් පසු සහ ජාල ගොඩට ස්පර්ශ කරන Windows යාවත්කාලීනයකින් පසු එය නැවත පරීක්ෂා කරන්න, මන්ද ඕනෑම එකකට භෞතික අනුවර්තකය නැවත ඉදිරියට ගෙන ඒමට හැකිය.

අදාළ ලිපි