ਕੀ VPN ਨੇ ਮੇਰਾ DNS ਬਦਲਿਆ? ਪਹਿਲਾਂ ਅਤੇ ਬਾਅਦ ਦੀ ਤੁਲਨਾ ਕਰੋ
ਇੱਕ ਪ੍ਰੋਫਾਈਲ ਤੁਹਾਡੀਆਂ ਕੁਐਰੀਆਂ ਜਾਣਬੁੱਝ ਕੇ ਹਿਲਾ ਸਕਦਾ ਹੈ। VPN ਜੁੜਨ ਤੋਂ ਪਹਿਲਾਂ ਅਤੇ ਬਾਅਦ ਰਿਜ਼ੌਲਵਰ ਨੀਤੀ ਅਤੇ ਅਸਲ ਜਵਾਬ ਦੀ ਤੁਲਨਾ ਕਰੋ, ਇੱਕ ਚਰ ਸਥਿਰ ਰੱਖਦਿਆਂ।
ਤੁਸੀਂ ਟਨਲ ਜੋੜਦੇ ਹੋ, ਨਿੱਜੀ ਡੈਸ਼ਬੋਰਡ ਖੋਲ੍ਹਦੇ ਹੋ, ਅਤੇ ਨਾਮ ਉਸ ਪਤੇ ’ਤੇ ਹੱਲ ਹੁੰਦਾ ਹੈ ਜੋ ਤੁਸੀਂ ਕਦੇ ਨਹੀਂ ਦੇਖਿਆ। ਜਾਂ ਉਲਟਾ ਹੁੰਦਾ ਹੈ: ਬ੍ਰਾਊਜ਼ਰ ਕੰਮ ਕਰਦਾ ਰਹਿੰਦਾ ਹੈ, ਪਰ ਕਮਾਂਡ-ਲਾਈਨ ਟੂਲ ਅਚਾਨਕ ਕੁਝ ਵੀ ਹੱਲ ਨਹੀਂ ਕਰਦਾ। ਦੋਵੇਂ ਨਤੀਜੇ ਇੱਕੋ ਬਦਲਾਅ ਤੋਂ ਆਉਂਦੇ ਹਨ, ਅਤੇ ਲੋਕ ਆਮ ਤੌਰ ’ਤੇ ਇਸਨੂੰ VPN "ਆਪਣਾ DNS ਵਰਤਦਾ ਹੈ" ਵਾਲੇ ਇੱਕ ਵਾਕ ਨਾਲ ਸਮਝਾਉਂਦੇ ਹਨ, ਜੋ ਡੀਬੱਗ ਕਰਨ ਜਾਂ ਪੁਸ਼ਟੀ ਕਰਨ ਲਈ ਕਾਫ਼ੀ ਸਟੀਕ ਨਹੀਂ ਹੈ। ਉਸ ਵਾਕ ਵਿੱਚ ਦੋ ਸਵਾਲ ਲੁਕੇ ਹੋਏ ਹਨ: ਇਹ ਪ੍ਰੋਫਾਈਲ ਕਿਹੜੀਆਂ ਕੁਐਰੀਆਂ ਲੈਣੀਆਂ ਹੈ, ਅਤੇ ਤੁਹਾਡੀ ਮਸ਼ੀਨ ਨੇ ਉਹ ਸੱਚਮੁੱਚ ਉਸ ਰਿਜ਼ੌਲਵਰ ਕੋਲ ਭੇਜੀਆਂ ਜੋ ਉਸਨੂੰ ਦਿੱਤਾ ਗਿਆ ਸੀ? ਉਹਨਾਂ ਨੂੰ ਵੱਖਰਾ ਰੱਖਣਾ ਹੀ ਪੂਰਾ ਤਰੀਕਾ ਹੈ, ਕਿਉਂਕਿ ਉਹਨਾਂ ਨੂੰ ਮਿਲਾਉਣ ਵਾਲਾ ਟੈਸਟ ਦੋਵੇਂ ਦਿਸ਼ਾਵਾਂ ਵਿੱਚ ਭਰੋਸੇਯੋਗ ਗਲਤ ਜਵਾਬ ਦਿੰਦਾ ਹੈ।
ਪ੍ਰੋਫਾਈਲ ਆਖ਼ਿਰ ਰਿਜ਼ੌਲਵਰ ਕਿਉਂ ਦਿੰਦਾ ਹੈ
ਟਨਲ ਦੇ ਅੰਦਰ, ਦੂਰਲੇ ਸਿਰੇ ਦੇ ਪਿੱਛੇ ਦੇ ਨਾਮ ਆਮ ਤੌਰ ’ਤੇ ਉਹਨਾਂ ਪਤਿਆਂ ’ਤੇ ਹੱਲ ਹੁੰਦੇ ਹਨ ਜੋ ਸਿਰਫ਼ ਉਸ ਨੈੱਟਵਰਕ ਵਿੱਚ ਹੁੰਦੇ ਹਨ। corp.internal ਵਰਗੇ ਨਿੱਜੀ ਜ਼ੋਨ ਦਾ ਕੋਈ ਜਨਤਕ ਵਫ਼ਦ ਨਹੀਂ ਹੁੰਦਾ, ਇਸ ਲਈ ਉਸਨੂੰ ਜਵਾਬ ਦੇਣ ਵਾਲਾ ਰਿਜ਼ੌਲਵਰ ਟਨਲ ਦੇ ਅੰਦਰੋਂ ਪਹੁੰਚਯੋਗ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਉਹੀ ਵਿਧੀ ਦੂਜੇ ਮਕਸਦ ਲਈ ਵੀ ਕੰਮ ਕਰਦੀ ਹੈ: ਜਦੋਂ ਕੁਐਰੀਆਂ ਹੋਰ ਥਾਂ ਤੁਹਾਡੇ ISP ਰਾਹੀਂ ਬਾਹਰ ਜਾਂਦੀਆਂ, ਤਾਂ ਦੂਰਲੇ ਪਾਸੇ ਦਾ ਰਿਜ਼ੌਲਵਰ ਕੁਐਰੀ ਨੂੰ ਐਨਕ੍ਰਿਪਟਡ ਰਸਤੇ ਦੇ ਅੰਦਰ ਰੱਖਦਾ ਹੈ। ਇਸੇ ਲਈ DNS ਸਰਵਰ ਦਾ ਪਤਾ ਕਨੈਕਸ਼ਨ ਦੀ ਨੀਤੀ ਦੇ ਹਿੱਸੇ ਵਜੋਂ ਆਉਂਦਾ ਹੈ, ਮਸ਼ੀਨ ਲਈ ਇੱਕ ਵਾਰ ਚੁਣੀ ਗਈ ਗਲੋਬਲ ਸੈਟਿੰਗ ਵਜੋਂ ਨਹੀਂ।
ਪਤਾ ਆਪਣੇ ਆਪ ਵਿੱਚ ਕੁਝ ਵੀ ਤੈਅ ਨਹੀਂ ਕਰਦਾ। ਰਿਜ਼ੌਲਵਰ ਤਾਂ ਹੀ ਜਵਾਬ ਦੇ ਸਕਦਾ ਹੈ ਜੇ ਉਸ ਤੱਕ ਰਸਤਾ ਹੋਵੇ, ਅਤੇ ਸਭ ਤੋਂ ਆਮ ਖਰਾਬੀ ਉਹ ਰਿਜ਼ੌਲਵਰ ਹੈ ਜੋ ਸਿਰਫ਼ ਟਨਲ ਚਾਲੂ ਹੋਣ ਵੇਲੇ ਪਹੁੰਚਯੋਗ ਹੁੰਦਾ ਹੈ। ਜਦੋਂ ਟਨਲ ਡਿੱਗਦਾ ਹੈ ਅਤੇ ਨੀਤੀ ਰਹਿੰਦੀ ਹੈ, ਕੁਐਰੀਆਂ ਬਿਨਾਂ ਰਸਤੇ ਵਾਲੇ ਪਤੇ ’ਤੇ ਜਾਂਦੀਆਂ ਹਨ, ਅਤੇ ਲੱਛਣ ਸਾਫ਼ ਗਲਤੀ ਨਹੀਂ ਸਗੋਂ ਸਮਾਂ ਸਮਾਪਤ ਹੋਣਾ ਹੈ। ਅਗਲਾ ਟੈਸਟ ਨਤੀਜਾ ਪੜ੍ਹਦਿਆਂ ਇਹ ਫ਼ਰਕ ਮਹੱਤਵਪੂਰਨ ਹੈ, ਕਿਉਂਕਿ ਸਮਾਂ ਸਮਾਪਤ ਹੋਣਾ ਲੋਕਾਂ ਨੂੰ ਉਹਨਾਂ ਟਰਾਂਸਪੋਰਟ ਸੈਟਿੰਗਾਂ ਵੱਲ ਭੇਜਦਾ ਹੈ ਜੋ ਕਦੇ ਸ਼ਾਮਲ ਨਹੀਂ ਸਨ।
ਜਵਾਬਾਂ ਦੀ ਤੁਲਨਾ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਦੋ ਡਿਜ਼ਾਈਨਾਂ ਦੀ ਤੁਲਨਾ ਕਰੋ
ਪੂਰਾ ਟਨਲ ਅਤੇ ਵੰਡਿਆ DNS ਉਲਟ ਉਮੀਦਾਂ ਪੈਦਾ ਕਰਦੇ ਹਨ, ਅਤੇ ਦੋਵੇਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਖਰਾਬੀ ਨਹੀਂ ਹੈ। ਪੂਰੇ ਟਨਲ ਹੇਠ ਹਰ ਕੁਐਰੀ ਪ੍ਰਦਾਤਾ ਜਾਂ ਕਾਰਪੋਰੇਟ ਰਿਜ਼ੌਲਵਰ ਕੋਲ ਜਾ ਸਕਦੀ ਹੈ, ਇਸ ਲਈ ਜੁੜਨ ਤੋਂ ਬਾਅਦ ਜਨਤਕ ਨਾਮਾਂ ਦਾ ਵੱਖਰਾ ਜਵਾਬ ਦੇਣਾ ਉਮੀਦਯੋਗ ਹੈ। ਵੰਡੇ DNS ਹੇਠ ਸਿਰਫ਼ ਸੂਚੀਬੱਧ ਡੋਮੇਨ ਨਿੱਜੀ ਰਿਜ਼ੌਲਵਰ ਕੋਲ ਜਾਂਦੇ ਹਨ, ਬਾਕੀ ਸਭ ਸਥਾਨਕ ਰਹਿੰਦਾ ਹੈ; Windows ਵਿੱਚ ਡੋਮੇਨ ਸੂਚੀ Name Resolution Policy Table ਵਿੱਚ, macOS ਵਿੱਚ DNS ਸੈਟਿੰਗਾਂ ਦੇ ਮੇਲ ਖਾਂਦੇ ਡੋਮੇਨਾਂ ਵਿੱਚ, ਅਤੇ systemd-resolved ਹੋਸਟ ’ਤੇ ਹਰ ਲਿੰਕ ਦੇ ਰੂਟਿੰਗ ਡੋਮੇਨਾਂ ਵਿੱਚ ਹੁੰਦੀ ਹੈ।
ਇਹੀ ਪਹਿਲਾਂ ਕਰਨ ਵਾਲੀ ਤੁਲਨਾ ਹੈ, ਕਿਉਂਕਿ ਇਹ ਤੈਅ ਕਰਦੀ ਹੈ ਕਿ ਕਿਸ ਨੂੰ ਖਰਾਬੀ ਮੰਨਣਾ ਹੈ। ਵੰਡੇ DNS ਵਿੱਚ, ਨਵੇਂ ਰਿਜ਼ੌਲਵਰ ਤੋਂ ਜਵਾਬ ਦੇਣ ਵਾਲਾ ਜਨਤਕ ਨਾਮ ਹੀ ਜਾਂਚਣ ਯੋਗ ਹੁੰਦਾ ਹੈ, ਜਦਕਿ ਸਹੀ ਜਵਾਬ ਦੇਣ ਵਾਲਾ ਅੰਦਰੂਨੀ ਨਾਮ ਸਿਸਟਮ ਦਾ ਆਪਣਾ ਕੰਮ ਕਰਨਾ ਹੈ। ਪੂਰੇ ਟਨਲ ਵਿੱਚ, ਅਸਧਾਰਨਤਾ ਉਹ ਜਨਤਕ ਨਾਮ ਹੈ ਜੋ ਅਜੇ ਵੀ ਤੁਹਾਡੇ ISP ਰਿਜ਼ੌਲਵਰ ਤੋਂ ਜਵਾਬ ਦਿੰਦਾ ਹੈ। Microsoft ਦੀ VPN ਨਾਮ ਹੱਲ ਬਾਰੇ ਦਸਤਾਵੇਜ਼ ਇਹਨਾਂ ਨਿਯਮਾਂ ਦਾ Windows ਕ੍ਰਮ ਦੱਸਦੀ ਹੈ, ਜਿਸ ਵਿੱਚ ਇਹ ਵੀ ਸ਼ਾਮਲ ਹੈ ਕਿ ਮੇਲ ਖਾਂਦੀ ਨੀਤੀ ਐਂਟਰੀ ਐਡਾਪਟਰ ਦੇ ਆਪਣੇ ਸਰਵਰਾਂ ਤੋਂ ਪਹਿਲਾਂ ਕਿਵੇਂ ਵਿਚਾਰੀ ਜਾਂਦੀ ਹੈ।
ਕਮਰੇ ਵਿੱਚ ਤੀਜਾ ਰਿਜ਼ੌਲਵਰ ਵੀ ਹੈ ਜਿਸਨੂੰ ਭੁੱਲਣਾ ਸੌਖਾ ਹੈ। ਬ੍ਰਾਊਜ਼ਰ ਦਾ ਸੁਰੱਖਿਅਤ DNS ਖੁਦ ਨਾਮ ਹੱਲ ਕਰਦਾ ਹੈ ਅਤੇ ਟਨਲ ਵੱਲੋਂ ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ ਦੀ ਨੀਤੀ ਬਦਲਣ ਤੋਂ ਬਾਅਦ ਵੀ ਜਵਾਬ ਦੇ ਸਕਦਾ ਹੈ, ਇਸ ਲਈ ਲੋਡ ਹੋਣ ਵਾਲਾ ਪੰਨਾ ਸਾਬਤ ਕਰਦਾ ਹੈ ਕਿ ਬ੍ਰਾਊਜ਼ਰ ਦਾ ਰਿਜ਼ੌਲਵਰ ਕੰਮ ਕੀਤਾ, ਇਹ ਨਹੀਂ ਕਿ ਪ੍ਰੋਫਾਈਲ ਲਾਗੂ ਹੋਇਆ। ਜੇ ਤੁਸੀਂ ਸਿਰਫ਼ ਉਹੀ ਤੁਲਨਾ ਕਰਦੇ ਹੋ ਜੋ ਬ੍ਰਾਊਜ਼ਰ ਦਿਖਾਉਂਦਾ ਹੈ, ਤਾਂ ਅੱਧਾ ਸਮਾਂ ਤੁਸੀਂ ਗਲਤ ਪਰਤ ਦੀ ਜਾਂਚ ਕਰ ਰਹੇ ਹੋ।
ਸਿਰਫ਼ ਇੱਕ ਚਰ ਨਾਲ ਅਧਾਰ-ਰੇਖਾ ਦਰਜ ਕਰੋ
ਟਨਲ ਬਦਲੋ। ਉਸੇ ਕਦਮ ਵਿੱਚ ਨਾਮ, ਟੂਲ ਜਾਂ ਖੋਜ ਪ੍ਰਤਿਅੈ ਵੀ ਨਾ ਬਦਲੋ। ਅਜਿਹਾ ਨਾਮ ਚੁਣੋ ਜਿਸ ਬਾਰੇ ਪੁੱਛਣ ਦੀ ਤੁਹਾਨੂੰ ਇਜਾਜ਼ਤ ਹੈ, ਨੋਟ ਕਰੋ ਕਿ ਕਿਹੜੀ ਐਪਲੀਕੇਸ਼ਨ ਵਰਤੀ, ਅਤੇ ਜਾਂ ਤਾਂ ਵਾਪਸ ਆਇਆ ਪਤਾ ਜਾਂ ਸਹੀ ਗਲਤੀ ਲਿਖੋ। Windows ਵਿੱਚ Get-DnsClientServerAddress -AddressFamily IPv4 ਹਰ ਐਡਾਪਟਰ ਦੇ ਸਰਵਰ ਛਾਪਦਾ ਹੈ ਅਤੇ Get-DnsClientNrptPolicy ਨੀਤੀ ਐਂਟਰੀਆਂ ਛਾਪਦਾ ਹੈ; systemd-resolved ਵਾਲੇ Linux ਵਿੱਚ resolvectl status ਹਰ ਲਿੰਕ ਦੇ DNS ਸਰਵਰ ਅਤੇ ਰੂਟਿੰਗ ਡੋਮੇਨ ਦਿਖਾਉਂਦਾ ਹੈ; macOS ਵਿੱਚ scutil --dns ਉਹ ਰਿਜ਼ੌਲਵਰ ਕ੍ਰਮ ਛਾਪਦਾ ਹੈ ਜਿਸਦਾ ਸਿਸਟਮ ਸੱਚਮੁੱਚ ਪਾਲਣ ਕਰੇਗਾ।
ਫਿਰ ਕਲਾਇੰਟ ਦੇ ਆਮ ਨਿਯੰਤਰਣਾਂ ਰਾਹੀਂ ਜੁੜੋ ਅਤੇ ਠੀਕ ਉਹੀ ਕਮਾਂਡਾਂ ਦੁਹਰਾਓ। ਪਹਿਲਾ ਆਉਟਪੁੱਟ ਯਾਦ ਰੱਖਣ ਦੀ ਥਾਂ ਸੰਭਾਲੋ, ਕਿਉਂਕਿ ਤੁਲਨਾ ਹੀ ਪੂਰਾ ਮੁੱਦਾ ਹੈ ਅਤੇ ਕੈਸ਼ ਖਾਲੀ ਕਰਨ ਤੋਂ ਬਾਅਦ ਲਿਆ ਦੂਜਾ ਪੜ੍ਹਨ ਪਹਿਲਾਂ ਹੀ ਵੱਖਰਾ ਮਾਪ ਹੈ। ਜੇ ਅਧਾਰ-ਰੇਖਾ ਬ੍ਰਾਊਜ਼ਰ ਸਾਹਮਣੇ ਰੱਖ ਕੇ ਲਈ ਗਈ ਸੀ ਅਤੇ ਜੁੜਨ ਤੋਂ ਬਾਅਦ ਦਾ ਕੰਮ ਟਰਮੀਨਲ ਵਿੱਚ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਦੋ ਰਿਜ਼ੌਲਵਰਾਂ ਦੀ ਤੁਲਨਾ ਕਰ ਰਹੇ ਹੋ, ਇੱਕ ਰਿਜ਼ੌਲਵਰ ਦੀਆਂ ਦੋ ਹਾਲਤਾਂ ਦੀ ਨਹੀਂ।
ਸਪਸ਼ਟ ਕੁਐਰੀ ਅਤੇ ਐਪਲੀਕੇਸ਼ਨ ਖੋਜ ਵੱਖਰੇ ਟੈਸਟ ਹਨ
ਇੱਕ ਖਾਸ ਸਰਵਰ ਨੂੰ ਪੁੱਛਣਾ, nslookup name 10.20.0.1 ਜਾਂ dig @10.20.0.1 name ਨਾਲ, ਇੱਕ ਗੱਲ ਸਾਬਤ ਕਰਦਾ ਹੈ: ਜਿਸ ਸਰਵਰ ਦਾ ਤੁਸੀਂ ਨਾਮ ਲਿਆ ਉਹ ਤਦ ਜਵਾਬ ਦਿੰਦਾ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਉਸ ਤੱਕ ਪਹੁੰਚ ਸਕਦੇ ਹੋ। ਇਹ ਚੋਣ ਤਰਕ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਬਾਈਪਾਸ ਕਰਦਾ ਹੈ, ਇਸ ਲਈ ਇਹ ਨਹੀਂ ਦੱਸ ਸਕਦਾ ਕਿ ਸਿਸਟਮ ਇਸ ਨਾਮ ਲਈ ਉਹ ਸਰਵਰ ਚੁਣਦਾ ਸੀ ਜਾਂ ਨਹੀਂ। ਇਸਨੂੰ ਇਹ ਜਾਂਚਣ ਲਈ ਵਰਤੋ ਕਿ ਨਿਯਤ ਰਿਜ਼ੌਲਵਰ ਪਹੁੰਚਯੋਗ ਹੈ ਜਾਂ ਨਹੀਂ, ਅਤੇ ਨੀਤੀ ਜਾਂਚਣ ਲਈ ਇਸਨੂੰ ਨਾ ਵਰਤੋ।
ਸਥਾਨਕ ਰਿਜ਼ੌਲਵਰ ਰਾਹੀਂ ਖੋਜ ਚੋਣ ਦੀ ਸੱਚਮੁੱਚ ਵਰਤੋਂ ਕਰਦੀ ਹੈ। resolvectl query name ਉਹੀ ਰੂਟਿੰਗ-ਡੋਮੇਨ ਨਿਯਮ ਚੱਲਦਾ ਹੈ ਅਤੇ ਦੱਸਦਾ ਹੈ ਕਿ ਕਿਹੜੇ ਪ੍ਰੋਟੋਕਾਲ ਨੇ ਜਵਾਬ ਦਿੱਤਾ, Windows ਵਿੱਚ Resolve-DnsName ਨੀਤੀ ਸਾਰਣੀ ਅਤੇ ਕਲਾਇੰਟ ਕੈਸ਼ ਵਿੱਚੋਂ ਲੰਘਦਾ ਹੈ, ਅਤੇ scutil --dns ਉਹ ਕ੍ਰਮ ਦਿਖਾਉਂਦਾ ਹੈ ਜਿਸਦਾ ਖੋਜ ਪਾਲਣ ਕਰੇਗੀ। ਦੋਵੇਂ ਕਿਸਮਾਂ ਚਲਾਓ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਆਪਣੇ ਨੋਟਾਂ ਦੇ ਵੱਖਰੇ ਕਾਲਮਾਂ ਵਿੱਚ ਰੱਖੋ। ਸਫਲ ਸਪਸ਼ਟ ਕੁਐਰੀ ਦੇ ਨਾਲ ਅਸਫਲ ਐਪਲੀਕੇਸ਼ਨ ਖੋਜ ਰੂਟਿੰਗ ਜਾਂ ਚੋਣ ਦੀ ਸਮੱਸਿਆ ਹੈ, ਕੰਮ ਕਰਨ ਤੋਂ ਇਨਕਾਰ ਕਰਨ ਵਾਲਾ ਰਿਜ਼ੌਲਵਰ ਨਹੀਂ।
ਕੈਸ਼ ਤੁਹਾਡੇ ਅਤੇ ਜਵਾਬ ਦੇ ਵਿਚਕਾਰ ਖੜ੍ਹਾ ਹੈ। ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ, ਸਥਾਨਕ ਸਟਬ ਰਿਜ਼ੌਲਵਰ, ਬ੍ਰਾਊਜ਼ਰ ਅਤੇ ਨਕਾਰਾਤਮਕ ਕੈਸ਼ ਸਾਰੇ ਨਤੀਜੇ ਰੱਖਦੇ ਹਨ, ਇਸ ਲਈ ਇੱਕ ਵੀ ਪੈਕੇਟ ਮਸ਼ੀਨ ਛੱਡੇ ਬਿਨਾਂ ਖੋਜ ਸਫਲ ਹੋ ਸਕਦੀ ਹੈ। ਕੁਝ ਵੀ ਖਾਲੀ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਨਤੀਜਾ ਦਰਜ ਕਰੋ: ipconfig /flushdns, resolvectl flush-caches ਜਾਂ macOS ਵਿੱਚ sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder। ਇਸ ਪੜਾਅ ’ਤੇ ਵਿਆਪਕ ਨੈੱਟਵਰਕ ਰੀਸੈਟ ਛੱਡੋ, ਕਿਉਂਕਿ ਇਹ ਉਹ ਸਬੂਤ ਨਸ਼ਟ ਕਰਦਾ ਹੈ ਜੋ ਤੁਸੀਂ ਅਜੇ ਇਕੱਠਾ ਕਰ ਰਹੇ ਹੋ।
ਇਸ ਫ਼ਰਕ ਦਾ ਕੀ ਅਰਥ ਹੈ
ਤੁਸੀਂ ਦਰਜ ਕੀਤੀਆਂ ਦੋ ਕਤਾਰਾਂ ਦੀ ਤੁਲਨਾ ਕਰੋ ਅਤੇ ਇੱਕ ਵੀ ਸੈਟਿੰਗ ਛੂਹਣ ਤੋਂ ਪਹਿਲਾਂ ਬਦਲਾਅ ਦੀ ਸ਼੍ਰੇਣੀ ਬਣਾਓ।
| Observation after connect | Most likely cause | Next step |
|---|---|---|
| Answer moves to a private address range | Expected under split DNS or a private zone | Confirm the suffix is in the effective policy, then test the service |
| Lookup times out while connected, works after disconnect | The assigned resolver has no route from this machine | Probe it with an explicit query, then re-read the policy |
| Internal name fails, public names work | Wrong namespace or a suffix missing from the policy | Query the fully qualified name and check the domain list per platform |
| Internal name returns a public address | Split DNS not applied; a public resolver answered | Check browser secure DNS first, then the per-link domain list |
ਇੱਕ ਕਤਾਰ ਵਿਸ਼ੇਸ਼ ਜ਼ੋਰ ਦੇ ਯੋਗ ਹੈ। ਹੱਲ ਹੋਣ ਵਾਲਾ ਨਾਮ ਕੰਮ ਕਰਦੀ ਸੇਵਾ ਨਹੀਂ ਹੈ, ਅਤੇ DNS ਦੀ ਸਫਲਤਾ ਸਿਰਫ਼ ਇਹ ਕਹਿੰਦੀ ਹੈ ਕਿ ਪਤਾ ਲੱਭਿਆ। ਇਹ ਫਾਰਵਰਡਿੰਗ, ਫਾਇਰਵਾਲ ਨਿਯਮਾਂ ਜਾਂ ਇਸ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਕਹਿੰਦੀ ਕਿ ਤੁਹਾਡਾ ਖਾਤਾ ਇਹ ਸੇਵਾ ਵਰਤ ਸਕਦਾ ਹੈ ਜਾਂ ਨਹੀਂ, ਇਸ ਲਈ ਇਹ ਮੰਨਣ ਦੀ ਥਾਂ ਕਿ ਖਰਾਬੀ ਆਪਣੇ ਆਪ ਚਲੀ ਗਈ, ਅਸਲ ਐਪਲੀਕੇਸ਼ਨ ਜਾਂਚ ਕੇ ਸਮਾਪਤ ਕਰੋ।
ਅਧਾਰ-ਰੇਖਾ ਬਹਾਲ ਕਰੋ ਅਤੇ ਪੁਸ਼ਟੀ ਕਰੋ
ਪ੍ਰਕਿਰਿਆ ਮਾਰਨ ਦੀ ਥਾਂ ਕਲਾਇੰਟ ਦੇ ਆਪਣੇ ਨਿਯੰਤਰਣਾਂ ਰਾਹੀਂ ਡਿਸਕਨੈਕਟ ਕਰੋ, ਫਿਰ ਉਹੀ ਤਿੰਨ ਕਮਾਂਡਾਂ ਦੁਬਾਰਾ ਪੜ੍ਹੋ। ਹਰ ਲਿੰਕ ਦੇ ਸਰਵਰ, ਨੀਤੀ ਐਂਟਰੀਆਂ ਅਤੇ ਤੁਹਾਡੇ ਟੈਸਟ ਨਾਮ ਦਾ ਜਵਾਬ ਪਹਿਲਾਂ ਲਿਖੀ ਅਧਾਰ-ਰੇਖਾ ’ਤੇ ਵਾਪਸ ਆਉਣਾ ਚਾਹੀਦਾ ਹੈ। ਸਾਫ਼ ਡਿਸਕਨੈਕਟ ਤੋਂ ਬਾਅਦ ਬਚੀ ਨੀਤੀ ਐਂਟਰੀ ਦਰਜ ਕਰਨ ਯੋਗ ਅਸਲ ਖਰਾਬੀ ਹੈ, ਅਤੇ ਇਸੇ ਲਈ ਬਣਾਈ ਗਈ ਰਿਜ਼ੌਲਵਰ ਫਾਈਲ ਵਿੱਚ ਹੱਥੀਂ ਸੋਧ ਕਰਨਾ ਮਾੜੀ ਆਦਤ ਹੈ: ਫਾਈਲ ਦੁਬਾਰਾ ਲਿਖੀ ਜਾਂਦੀ ਹੈ ਅਤੇ ਸੋਧ ਗਾਇਬ ਹੋ ਜਾਂਦੀ ਹੈ, ਜਾਂ ਸੋਧ ਬਚੀ ਰਹਿੰਦੀ ਹੈ ਅਤੇ ਹੁਣ ਰਸਤਾ ਨਾ ਰੱਖਣ ਵਾਲੇ ਰਿਜ਼ੌਲਵਰ ਨੂੰ ਪਿੰਨ ਕਰ ਦਿੰਦੀ ਹੈ।
ਇਹ ਸੂਚੀ ਇੱਕ ਵਾਰ, ਕ੍ਰਮ ਵਿੱਚ ਕਰੋ। ਕੋਈ ਵੀ ਨਤੀਜਾ ਨਿਰਣਾ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਤੈਅ ਕਰੋ ਕਿ ਪ੍ਰੋਫਾਈਲ ਕਿਹੜਾ ਡਿਜ਼ਾਈਨ ਲਾਗੂ ਕਰਦਾ ਹੈ। ਦੋਵੇਂ ਦੌੜਾਂ ਵਿੱਚ ਨਾਮ, ਟੂਲ ਅਤੇ ਪ੍ਰਤਿਅੈ ਸਥਿਰ ਰੱਖੋ। ਸਪਸ਼ਟ ਕੁਐਰੀ ਨੂੰ ਐਪਲੀਕੇਸ਼ਨ ਖੋਜ ਤੋਂ ਵੱਖ ਰੱਖੋ। ਸਿਰਫ਼ ਜਵਾਬ ਨਹੀਂ, ਪ੍ਰਭਾਵੀ ਨੀਤੀ ਪੜ੍ਹੋ। ਤੁਲਨਾ ਲਿਖਣ ਤੋਂ ਬਾਅਦ ਕੈਸ਼ ਅੰਤ ਵਿੱਚ ਖਾਲੀ ਕਰੋ। ਅਸਲ ਐਪਲੀਕੇਸ਼ਨ ਨਾਲ ਪੁਸ਼ਟੀ ਕਰੋ, ਫਿਰ ਇੱਕ ਵਾਰ ਰੀਬੂਟ ਕਰੋ ਅਤੇ ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਡਿਸਕਨੈਕਟ ਹਾਲਤ ਅਜੇ ਵੀ ਸਾਫ਼ ਹੈ।