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 અપડેટ પછી તેને ફરી તપાસો, કારણ કે બંનેમાંથી કોઈ પણ ભૌતિક એડાપ્ટરને ફરી આગળ લાવી શકે છે.