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 ਅੱਪਡੇਟ ਤੋਂ ਬਾਅਦ ਇਸਨੂੰ ਦੁਬਾਰਾ ਜਾਂਚੋ, ਕਿਉਂਕਿ ਇਹਨਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਭੌਤਿਕ ਅਡਾਪਟਰ ਨੂੰ ਫਿਰ ਅੱਗੇ ਲਿਆ ਸਕਦਾ ਹੈ।