Windows VPN-ൽ തെറ്റായ DNS സെർവർ: മെട്രിക്, ബൈൻഡിംഗ് ക്രമം അല്ലെങ്കിൽ പ്രത്യയം
Windows-ന്റെ മൂന്ന് സംവിധാനങ്ങൾ DNS റിസോൾവർ തിരഞ്ഞെടുക്കുന്നു, അവ വ്യത്യസ്ത രീതിയിൽ പരാജയപ്പെടുന്നു. നാമസ്ഥല വ്യാപ്തി, ആഗോള ക്രമം, അല്ലെങ്കിൽ പരിഹാരം വീണ്ടും ബന്ധിപ്പിക്കൽ അതിജീവിക്കുമോ എന്നതിനെ അടിസ്ഥാനമാക്കി തീരുമാനിക്കുക.
Windows ക്ലയന്റിന് പ്രവർത്തിക്കുന്ന ടണൽ ഉണ്ടാകാം, കോർപ്പറേറ്റ് റിസോൾവർ വഹിക്കാം, എങ്കിലും ആന്തരിക നാമങ്ങൾ വീട്ടിലെ റൂട്ടറിലേക്ക് അയയ്ക്കാം. ഏത് സെർവർ ഉത്തരം നൽകുമെന്ന് മൂന്ന് വ്യത്യസ്ത സംവിധാനങ്ങൾ തീരുമാനിക്കുന്നു, അവ വ്യത്യസ്ത രീതിയിൽ പരാജയപ്പെടുന്നു. മൂന്നും ശരിയാക്കേണ്ടതില്ല: ഏതാണ് കളിയിലുള്ളതെന്ന് ലക്ഷണം പറയുന്നു. താഴെയുള്ള തീരുമാന മരം കുറച്ച് മിനിറ്റ് എടുക്കുന്നു, മെട്രിക് മാറ്റവും രജിസ്ട്രി പുനഃക്രമീകരണവും NRPT നിയമവും ഒരുമിച്ച് വന്ന് ആർക്കും എന്ത് ചെയ്തുവെന്ന് അറിയാത്ത സാധാരണ അവസാനം തടയുന്നു.
മൂന്ന് സംവിധാനങ്ങൾ തീരുമാനിക്കുന്നു, സാധാരണയായി ഒന്ന് തെറ്റാണ്
ഇന്റർഫേസ് മെട്രിക് ഒരു നിർദ്ദിഷ്ട വിലാസ കുടുംബത്തിന് അഡാപ്റ്ററുകൾ ക്രമീകരിക്കുന്നു. Tcpip\Linkage പ്രകാരമുള്ള ബൈൻഡിംഗ് ക്രമം, പഴയ കോഡ് പാതകൾ ഇപ്പോഴും പരിശോധിക്കുന്ന യന്ത്രതലത്തിലുള്ള ഇന്റർഫേസ് ഐഡന്റിഫയറുകളുടെ പട്ടികയാണ്. നാമ വിശകലന നയ പട്ടിക (NRPT) ഒരു നാമസ്ഥലത്തെ നിർദ്ദിഷ്ട സെർവറുകളുമായി ബന്ധിപ്പിക്കുന്നു, പ്രത്യയ പട്ടിക ഒരു ചെറിയ നാമം വിപുലീകരിക്കുമോ എന്ന് തീരുമാനിക്കുന്നു. അവ സ്വതന്ത്രമാണ്, അതിനാൽ VPN അഡാപ്റ്ററിലെ ശരിയായ റിസോൾവർ മറ്റെവിടെയോ ഉള്ള പഴയ മുൻഗണനയോട് തോൽക്കുന്നു.
| What you see | Mechanism to check | First command |
|---|---|---|
| Every name is slow, public names sometimes wrong | Global adapter order: metric, then Linkage | Get-NetIPInterface |
| Internal names resolve to a public address | The query left through the home resolver, not the tunnel | Resolve-DnsName intranet.corp.example -Type A, then the same query with -Server 10.20.0.10 |
| Only corp.example names fail, public names fine | Namespace binding: NRPT or suffix | Get-DnsClientNrptRule |
| Short name fails, fully qualified name works | Suffix list on the adapter, with the corporate suffix ahead of other entries, or pushed by the server | Get-DnsClientGlobalSetting |
| Works, then breaks after a reconnect | Runtime setting that was never persisted | Get-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, InterfaceMetricLAN അഡാപ്റ്ററിൽ 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 അപ്ഡേറ്റിന് ശേഷവും അത് വീണ്ടും പരിശോധിക്കുക, കാരണം ഇവയിൽ ഏതും ഭൗതിക അഡാപ്റ്ററിനെ വീണ്ടും മുന്നിലെത്തിക്കാം.