ਤੁਹਾਡਾ VPN ਤਿੰਨ DNS ਸਰਵਰ ਭੇਜਦਾ ਹੈ: ਕਿਹੜਾ ਜਵਾਬ ਦਿੰਦਾ ਹੈ?
ਵਾਧੂ ਐਂਟਰੀਆਂ ਫਾਲਬੈਕ, ਪ੍ਰਤੀ-ਡੋਮੇਨ ਰੂਟ ਜਾਂ ਭੌਤਿਕ ਲਿੰਕ ਦਾ ਬਚਿਆ ਹੋਇਆ ਹਿੱਸਾ ਹੋ ਸਕਦੀਆਂ ਹਨ। ਸੂਚੀ ਨੂੰ ਲੀਕ ਕਹਿਣ ਤੋਂ ਪਹਿਲਾਂ ਹਰ ਇੱਕ ਨੂੰ ਇੱਕ ਦਾਇਰੇ ਨਾਲ ਜੋੜੋ।
ਕਨੈਕਟ ਕਰਨ ਤੋਂ ਬਾਅਦ ਸੈਟਿੰਗਾਂ ਪੰਨਾ ਖੋਲ੍ਹੋ ਅਤੇ ਤਿੰਨ DNS ਪਤੇ ਸੂਚੀਬੱਧ ਦਿਖਣਗੇ; ਆਡਿਟ ਦਾ ਸਵਾਲ ਇਹ ਹੈ ਕਿ ਤੁਹਾਡੀ ਆਖਰੀ ਕਵੈਰੀ ਕਿਸ ਨੇ ਸੰਭਾਲੀ। ਸਿਰਫ਼ ਗਿਣਤੀ ਕਿਸੇ ਵੀ ਗੱਲ ਦਾ ਜਵਾਬ ਨਹੀਂ ਦਿੰਦੀ, ਕਿਉਂਕਿ ਕਲਾਇੰਟ ਪੁਸ਼, ਇੱਕ ਭੌਤਿਕ ਇੰਟਰਫ਼ੇਸ ਅਤੇ ਪ੍ਰਤੀ-ਡੋਮੇਨ ਨੀਤੀ ਸਾਰੇ ਇੱਕੋ ਦ੍ਰਿਸ਼ ਵਿੱਚ ਲਿਖਦੇ ਹਨ। ਇਹਨਾਂ ਐਂਟਰੀਆਂ ਦੇ ਵੱਖਰੇ ਦਾਇਰੇ ਹਨ, ਅਤੇ ਜਵਾਬ ਕੌਣ ਦੇਵੇਗਾ ਇਹ ਸਥਿਤੀ ਨਹੀਂ, ਦਾਇਰਾ ਤੈਅ ਕਰਦਾ ਹੈ। ਸਰੋਤ ਵੱਖ ਕਰਕੇ ਸ਼ੁਰੂ ਕਰੋ, ਫਿਰ ਉਹ ਸਰੋਤ ਜਾਂਚੋ ਜਿਸ ਕੋਲ ਤੁਹਾਡੇ ਲਈ ਮਹੱਤਵਪੂਰਨ ਨਾਮ ਹੈ।
ਸੂਚੀ ਤੁਹਾਡੀ ਪ੍ਰੋਫ਼ਾਈਲ ਨਾਲੋਂ ਲੰਮੀ ਕਿਉਂ ਹੈ
VPN ਕਲਾਇੰਟ ਟਨਲ ਲਿੰਕ ਲਈ ਰਿਜ਼ੌਲਵਰ ਪਤੇ ਪੁਸ਼ ਕਰਦਾ ਹੈ, ਅਤੇ ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ ਉਹਨਾਂ ਨੂੰ ਭੌਤਿਕ ਇੰਟਰਫ਼ੇਸ ਕੋਲ ਪਹਿਲਾਂ ਹੀ ਜੋ ਸੀ ਉਸ ਦੇ ਕੋਲ ਰੱਖਦਾ ਹੈ। ਰਾਊਟਰ, ਕਾਰਪੋਰੇਟ DHCP ਲੀਜ਼, ਦੂਜਾ VPN ਅਤੇ ਪ੍ਰਤੀ-ਡੋਮੇਨ ਨੀਤੀ ਹਰ ਇੱਕ ਆਪਣੀ ਐਂਟਰੀ ਜੋੜਦਾ ਹੈ। ਇਸ ਲਈ ਪੰਨੇ ਉੱਤੇ ਤਿੰਨ ਪਤਿਆਂ ਦਾ ਮਤਲਬ ਇੱਕ ਕੰਮ ਲਈ ਤਿੰਨ ਉਮੀਦਵਾਰ ਨਹੀਂ, ਸਗੋਂ ਤਿੰਨ ਦਾਇਰੇ ਹੋ ਸਕਦੇ ਹਨ। ਗਿਣਤੀ ਨੂੰ ਲੀਕ ਦਾ ਸਬੂਤ ਪੜ੍ਹਨਾ ਇਸ ਆਡਿਟ ਦੀ ਪਹਿਲੀ ਗਲਤੀ ਹੈ।
ਇੱਕ ਇੰਟਰਫ਼ੇਸ ਦੇ ਅੰਦਰ ਕਲਾਇੰਟ ਸੱਚਮੁੱਚ ਆਪਣੇ ਸਰਵਰ ਕ੍ਰਮ ਵਿੱਚ ਅਜ਼ਮਾਉਂਦਾ ਹੈ, ਇਸ ਲਈ ਕ੍ਰਮਬੱਧ ਸੂਚੀ ਅਰਥਹੀਣ ਨਹੀਂ। ਜੋ ਕਤਾਰ ਨਹੀਂ ਹੈ ਉਹ ਮਿਲਿਆ-ਜੁਲਿਆ ਦ੍ਰਿਸ਼ ਹੈ, ਜਿੱਥੇ ਪ੍ਰੋਫ਼ਾਈਲ, ਭੌਤਿਕ ਲਿੰਕ ਅਤੇ ਪ੍ਰਤੀ-ਡੋਮੇਨ ਨਿਯਮਾਂ ਦੀਆਂ ਐਂਟਰੀਆਂ ਇੱਕ ਵੀ ਦਰਜਾਬੰਦੀ ਤੋਂ ਬਿਨਾਂ ਨਾਲ-ਨਾਲ ਬੈਠਦੀਆਂ ਹਨ। ਇਹੀ ਫ਼ਰਕ ਤੈਅ ਕਰਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਕੀ ਜਾਂਚੋਗੇ: ਕ੍ਰਮ ਇੱਕ ਦਾਇਰੇ ਦੇ ਅੰਦਰ ਵਿਵਹਾਰ ਸਮਝਾਉਂਦਾ ਹੈ, ਅਤੇ ਦਾਇਰਾ ਬਾਕੀ ਸਭ ਕੁਝ।
ਇਨਕ੍ਰਿਪਟਿਡ DNS ਤਸਵੀਰ ਨੂੰ ਐਪਲੀਕੇਸ਼ਨ ਦੇ ਅੰਦਰੋਂ ਤੋੜਦਾ ਹੈ। ਆਪਣਾ DNS-over-HTTPS ਰਿਜ਼ੌਲਵਰ ਰੱਖਣ ਵਾਲਾ ਬ੍ਰਾਊਜ਼ਰ ਜਾਂ ਚੈਟ ਕਲਾਇੰਟ ਕਵੈਰੀਆਂ ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ ਦੀ ਸੂਚੀ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਬਾਈਪਾਸ ਕਰਕੇ ਭੇਜਦਾ ਹੈ, ਇਸ ਲਈ ਸੈਟਿੰਗਾਂ ਪੰਨੇ ਦੇ ਪਤੇ ਅਜਿਹੇ ਟ੍ਰੈਫ਼ਿਕ ਦਾ ਵਰਣਨ ਕਰਦੇ ਹਨ ਜੋ ਐਪ ਨੇ ਕਦੇ ਪੈਦਾ ਨਹੀਂ ਕੀਤਾ। ਨਾਮ ਗਲਤ ਆਉਣ ਲਈ ਪ੍ਰੋਫ਼ਾਈਲ ਨੂੰ ਦੋਸ਼ ਦੇਣ ਤੋਂ ਪਹਿਲਾਂ ਐਪ ਦੀ ਆਪਣੀ ਰਿਜ਼ੌਲਵਰ ਸੈਟਿੰਗ ਜਾਂਚੋ।
ਤਿੰਨ ਜਾਂਚਾਂ ਵਿੱਚੋਂ ਹਰ ਇੱਕ ਕੀ ਕਹਿੰਦੀ ਹੈ
ਹਰ ਸਰੋਤ ਆਪਣਾ ਨਿਸ਼ਾਨ ਵੱਖਰੀ ਜਗ੍ਹਾ ਛੱਡਦਾ ਹੈ, ਅਤੇ ਕੋਈ ਇੱਕ ਕਮਾਂਡ ਸਭ ਨਹੀਂ ਦਿਖਾਉਂਦੀ। ਸੈਟਿੰਗਾਂ ਪੰਨੇ ਦੇ ਕੋਲ ਰੱਖਣ ਯੋਗ ਮੈਪਿੰਗ ਇਹ ਹੈ:
| Entry source | Where it is visible | What it proves |
|---|---|---|
| Tunnel profile | Link-scoped DNS on the tunnel device | Which servers the VPN asked you to use, not which one answered |
| Per-domain policy | Suffix list or routing domains | Which names are steered to a particular resolver |
| Physical link | DNS on the LAN interface | Whether a second scope still exists outside the tunnel |
| Application resolver | App settings, absent from the OS list | Whether the system list was consulted at all |
systemd-resolved ਵਰਤਣ ਵਾਲੇ ਸਿਸਟਮ ਉੱਤੇ resolvectl status ਅਧਿਕਾਰਿਕ ਹੈ, ਕਿਉਂਕਿ ਇਹ ਰਾਊਟਿੰਗ ਡੋਮੇਨਾਂ ਨਾਲ ਹਰ ਲਿੰਕ ਦਾ DNS ਰਿਪੋਰਟ ਕਰਦੀ ਹੈ। macOS scutil --dns ਰਾਹੀਂ ਜਵਾਬ ਦਿੰਦਾ ਹੈ, ਜੋ ਦਾਇਰਾ ਵਾਲੇ ਰਿਜ਼ੌਲਵਰਾਂ ਨੂੰ ਅਜ਼ਮਾਉਣ ਦੇ ਕ੍ਰਮ ਵਿੱਚ ਸੂਚੀਬੱਧ ਕਰਦਾ ਹੈ। Windows ਦੋ ਅੱਧੇ ਹਿੱਸੇ ਕਰਦਾ ਹੈ: ਪ੍ਰਤੀ-ਇੰਟਰਫ਼ੇਸ ਸਰਵਰਾਂ ਲਈ Get-DnsClientServerAddress ਅਤੇ ਸਫ਼ਿਕਸ ਨਿਯਮਾਂ ਲਈ Get-DnsClientNrptPolicy। ਅਸਲ ਵਿੱਚ ਵਰਤੇ ਜਾ ਰਹੇ ਰਿਜ਼ੌਲਵਰ ਨਾਲ ਸੰਬੰਧਿਤ ਕਮਾਂਡ ਚਲਾਓ, ਕਿਉਂਕਿ ਕੰਟੇਨਰ ਰਨਟਾਈਮ ਅਤੇ ਡੈਸਕਟਾਪ ਰਿਜ਼ੌਲਵਰ ਵਾਲੀ ਮਸ਼ੀਨ ਵਿੱਚ ਇੱਕ ਤੋਂ ਵੱਧ ਸਥਾਪਿਤ ਹੋ ਸਕਦੇ ਹਨ।
ਤੁਹਾਡੇ ਜ਼ੋਨ ਦਾ ਜਵਾਬ ਨਾ ਦੇ ਸਕਣ ਵਾਲਾ ਬੈਕਅਪ ਰਿਜ਼ੌਲਵਰ
ਦੂਜੀ ਐਂਟਰੀ ਆਮ ਤੌਰ ਉੱਤੇ ਉਪਲਬਧਤਾ ਲਈ ਹੁੰਦੀ ਹੈ, ਅਤੇ ਉਪਲਬਧਤਾ ਤਦ ਹੀ ਕੰਮ ਕਰਦੀ ਹੈ ਜਦੋਂ ਬੈਕਅਪ ਨੂੰ ਨਾਮ ਪਤਾ ਹੋਣ। ਕਿਸੇ ਜਨਤਕ ਰਿਜ਼ੌਲਵਰ ਨੂੰ ਅੰਦਰੂਨੀ ਹੋਸਟਨਾਮ ਪੁੱਛੋ, ਉਹ NXDOMAIN ਵਾਪਸ ਕਰਦਾ ਹੈ, ਜਾਂ ਤੁਹਾਡੇ ਨਾਲ ਕੋਈ ਸੰਬੰਧ ਨਾ ਰੱਖਣ ਵਾਲੇ ਖੋਜ ਡੋਮੇਨ ਤੋਂ ਵਾਈਲਡਕਾਰਡ ਜਵਾਬ ਦਿੰਦਾ ਹੈ। ਕਿਸੇ ਨੇ ਨਾ ਜਾਂਚਿਆ ਫੇਲਓਵਰ ਫਿਰ ਠੀਕ ਉਸੇ ਪਲ ਰੁਕਾਵਟ ਪੈਦਾ ਕਰਦਾ ਹੈ ਜਦੋਂ ਉਸ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ।
Split DNS ਇਹ ਰੋਕਣ ਲਈ ਹੈ: ਕੰਪਨੀ ਦੇ ਸਫ਼ਿਕਸ ਜ਼ੋਨ ਰੱਖਣ ਵਾਲੇ ਰਿਜ਼ੌਲਵਰ ਕੋਲ ਜਾਂਦੇ ਹਨ, ਅਤੇ ਜਨਤਕ ਨਾਮ ਡਿਫ਼ਾਲਟ ਮਾਰਗ ਉੱਤੇ ਰਹਿੰਦੇ ਹਨ। ਡਿਜ਼ਾਈਨ ਮਜ਼ਬੂਤ ਹੈ, ਅਤੇ ਇਹ ਸਫ਼ਿਕਸ ਸੂਚੀ ਪੂਰੀ ਹੋਣ ਉੱਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ। Microsoft ਪ੍ਰਤੀ-ਸਫ਼ਿਕਸ ਰਿਜ਼ੌਲਵਰ ਨੀਤੀ ਦਾ ਦਸਤਾਵੇਜ਼ੀਕਰਨ ਕਰਦਾ ਹੈ, ਜੋ Windows ਉੱਤੇ ਇਹ ਚਲਾਉਂਦੀ ਹੈ, ਅਤੇ ਉਹੀ ਵਿਚਾਰ systemd-resolved ਵਿੱਚ ਰਾਊਟਿੰਗ ਡੋਮੇਨ ਅਤੇ macOS ਉੱਤੇ ਦਾਇਰਾ ਵਾਲੇ ਰਿਜ਼ੌਲਵਰ ਵਜੋਂ ਦਿਖਦਾ ਹੈ।
ਬੈਕਅਪ ਜਿਹੜੇ ਜ਼ੋਨਾਂ ਦਾ ਜਵਾਬ ਦੇ ਸਕਦਾ ਹੈ ਉਹਨਾਂ ਦੀ ਨੀਤੀ ਵਿੱਚ ਮੌਜੂਦ ਸਫ਼ਿਕਸਾਂ ਨਾਲ ਤੁਲਨਾ ਕਰੋ। ਇਹ ਤੁਲਨਾ ਵਰਤੋਂਕਾਰ ਦੇ ਇਹ ਦੱਸਣ ਤੋਂ ਪਹਿਲਾਂ ਹੀ ਖੱਪਾ ਲੱਭ ਲੈਂਦੀ ਹੈ ਕਿ ਟਨਲ ਤਬਦੀਲੀ ਤੋਂ ਬਾਅਦ ਇੱਕ ਅੰਦਰੂਨੀ ਸਾਈਟ ਹੱਲ ਹੋਣਾ ਬੰਦ ਹੋ ਗਈ।
ਨੀਤੀ ਰਾਹੀਂ ਪੁੱਛੋ, ਉਸ ਦੁਆਲੇ ਨਹੀਂ
ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ ਦੇ ਰਿਜ਼ੌਲਵਰ ਰਾਹੀਂ ਪੁੱਛੋ, ਕਿਉਂਕਿ ਸਰਵਰ ਨੂੰ ਸਿੱਧੀ ਕਵੈਰੀ ਨੀਤੀ ਨੂੰ ਬਾਈਪਾਸ ਕਰਦੀ ਹੈ ਅਤੇ ਸਿਰਫ਼ ਉਹੀ ਦੱਸਦੀ ਹੈ ਜੋ ਉਹ ਸਰਵਰ ਕਹੇਗਾ। ਦੋ ਜਵਾਬਾਂ ਵਿਚਕਾਰਲਾ ਖੱਪਾ ਹੀ ਪੂਰੀ ਗੱਲ ਹੈ:
resolvectl query intranet.example.com
dig +short intranet.example.com @198.51.100.53ਜੇ ਸਿਸਟਮ ਕਵੈਰੀ ਨਿੱਜੀ ਪਤਾ ਵਾਪਸ ਕਰਦੀ ਹੈ ਜਦੋਂ ਕਿ ਸਿੱਧੀ ਕਵੈਰੀ NXDOMAIN ਵਾਪਸ ਕਰਦੀ ਹੈ, ਤਾਂ ਨੀਤੀ ਕੰਮ ਕਰ ਰਹੀ ਹੈ ਅਤੇ ਕਮਜ਼ੋਰ ਥਾਂ ਬੈਕਅਪ ਹੈ। ਜੇ ਦੋਵੇਂ ਇੱਕੋ ਜਨਤਕ ਜਵਾਬ ਵਾਪਸ ਕਰਦੇ ਹਨ, ਤਾਂ ਨਾਮ ਤੁਹਾਡੇ ਇੱਛਤ ਦਾਇਰੇ ਤੋਂ ਬਾਹਰ ਹੱਲ ਹੋ ਰਿਹਾ ਹੈ, ਅਤੇ ਸਫ਼ਿਕਸ ਸੂਚੀ ਵੇਖਣ ਦੀ ਜਗ੍ਹਾ ਹੈ। ਦੋਵੇਂ ਆਉਟਪੁੱਟ ਰੱਖੋ, ਕਿਉਂਕਿ ਸੈਟਿੰਗਾਂ ਪੰਨੇ ਦੇ ਸਕ੍ਰੀਨਸ਼ਾਟ ਨਾਲੋਂ ਦੋ ਲਾਈਨਾਂ ਨਾਲ ਰਿਜ਼ੌਲਵਰ ਬਹਿਸ ਛੇਤੀ ਮੁੱਕਦੀ ਹੈ।
ਫਿਰ ਅਸਫਲਤਾ ਦਾ ਮਾਰਗ ਅਭਿਆਸ ਕਰੋ, ਕਿਉਂਕਿ ਕਿਸੇ ਨੇ ਨਾ ਜਾਂਚਿਆ ਫਾਲਬੈਕ ਇੱਕ ਅੰਦਾਜ਼ਾ ਹੈ। ਇੱਕ ਕਵੈਰੀ ਲਈ ਪਸੰਦੀਦਾ ਰਿਜ਼ੌਲਵਰ ਨੂੰ ਬਲੈਕਹੋਲ ਬਣਾਓ ਅਤੇ ਵੇਖੋ ਕਿਹੜਾ ਪਤਾ ਵਾਪਸ ਆਉਂਦਾ ਹੈ:
ip route add blackhole 198.51.100.53/32
resolvectl query intranet.example.com
ip route del blackhole 198.51.100.53/32ਕਵੈਰੀ ਮੁੱਕਦਿਆਂ ਹੀ ਉਹ ਰੂਟ ਹਟਾ ਦਿਓ, ਨਹੀਂ ਤਾਂ ਅਗਲੇ ਵਿਅਕਤੀ ਨੂੰ ਇੱਕ ਬੁਝਾਰਤ ਵਿਰਾਸਤ ਵਿੱਚ ਮਿਲਦੀ ਹੈ। ਜੇ ਉਸ ਸਮੇਂ ਦੌਰਾਨ ਅੰਦਰੂਨੀ ਨਾਮ ਅਜੇ ਵੀ ਹੱਲ ਹੁੰਦੇ ਹਨ, ਤਾਂ ਇੱਛਤ ਦਾਇਰੇ ਤੋਂ ਬਾਹਰ ਦੀ ਕਿਸੇ ਚੀਜ਼ ਨੇ ਉਹਨਾਂ ਦਾ ਜਵਾਬ ਦਿੱਤਾ। ਜੇ ਉਹਨਾਂ ਦੀ ਥਾਂ ਸਮਾਂ ਮੁੱਕ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਫਾਲਬੈਕ ਨਹੀਂ ਹੈ ਜਾਂ ਸਹੀ ਢੰਗ ਨਾਲ ਸੀਮਿਤ ਹੈ, ਅਤੇ ਰਿਜ਼ੌਲਵਰ ਦਾ ਆਪਣਾ ਲੌਗ ਦੱਸਦਾ ਹੈ ਕਿ ਦੋਹਾਂ ਵਿੱਚੋਂ ਕਿਹੜਾ ਸੀ।
ਫੈਸਲਾ ਕਰੋ: ਰੱਖੋ, ਸੀਮਿਤ ਕਰੋ ਜਾਂ ਹਟਾਓ
ਦੂਜਾ ਰਿਜ਼ੌਲਵਰ ਤਦ ਰੱਖੋ ਜਦੋਂ ਇਹ ਤੁਹਾਨੂੰ ਲੋੜੀਂਦੇ ਨਾਮ ਥਾਂ ਦਾ ਜਵਾਬ ਦਿੰਦਾ ਹੈ ਅਤੇ ਪ੍ਰੋਫ਼ਾਈਲ ਹੇਠ ਪਹੁੰਚਯੋਗ ਰਹਿੰਦਾ ਹੈ। ਇਸ ਨੂੰ ਤਦ ਸੀਮਿਤ ਕਰੋ ਜਦੋਂ ਇਸ ਨੂੰ ਸਿਰਫ਼ ਇੱਕ ਸਫ਼ਿਕਸ ਅਤੇ ਹੋਰ ਕੁਝ ਨਹੀਂ ਵੇਖਣਾ ਚਾਹੀਦਾ, ਅਤੇ ਇਸ ਨੂੰ ਹਟਾ ਦਿਓ ਜਦੋਂ ਇਸ ਦਾ ਨਾ ਦਾਇਰਾ ਹੈ ਨਾ ਦਸਤਾਵੇਜ਼ੀ ਉਦੇਸ਼। ਕੰਮ ਤੋਂ ਬਿਨਾਂ ਐਂਟਰੀ ਲਾਭ ਤੋਂ ਬਿਨਾਂ ਭਵਿੱਖ ਦੀ ਲੀਕ ਹੈ, ਅਤੇ ਵਿਕਰੇਤਾ ਦਾ ਡਿਫ਼ਾਲਟ ਉਦੇਸ਼ ਨਹੀਂ ਹੈ।
ਨਤੀਜਾ ਚਾਰ ਕਾਲਮਾਂ ਵਿੱਚ ਦਰਜ ਕਰੋ: ਸਫ਼ਿਕਸ, ਰਿਜ਼ੌਲਵਰ, ਇੰਟਰਫ਼ੇਸ ਅਤੇ ਮਾਲਕ। ਉਹ ਲਾਈਨ ਕਿਸੇ ਵੀ ਸਕ੍ਰੀਨਸ਼ਾਟ ਨਾਲੋਂ ਛੇਤੀ ਅਗਲੇ ਆਡਿਟ ਸਵਾਲ ਦਾ ਜਵਾਬ ਦਿੰਦੀ ਹੈ, ਅਤੇ ਸੂਚੀ ਨੂੰ ਚੁੱਪਚਾਪ ਮੁੜ-ਕ੍ਰਮਬੱਧ ਕਰਨ ਵਾਲੇ ਕਲਾਇੰਟ ਅੱਪਡੇਟ ਤੋਂ ਵੀ ਬਚੀ ਰਹਿੰਦੀ ਹੈ।