VPN ਡਿਸਕਨੈਕਟ ਹੋਣ ਤੋਂ ਬਾਅਦ resolv.conf ਸੋਧਣ ਨਾਲ DNS ਠੀਕ ਨਹੀਂ ਹੁੰਦਾ

ਤੁਸੀਂ VPN ਡਿਸਕਨੈਕਟ ਕਰਦੇ ਹੋ, ping 1.1.1.1 ਅਜੇ ਵੀ ਜਵਾਬ ਦਿੰਦਾ ਹੈ, ਅਤੇ ਪੰਨਾ ਅੰਤ ਵਿੱਚ ਹਾਰ ਮੰਨਣ ਤੋਂ ਪਹਿਲਾਂ ਹਰ ਨਾਮ ਖੋਜ ਲਟਕਦੀ ਹੈ। ਫਿਰ cat /etc/resolv.conf ਉਹ ਨੇਮਸਰਵਰ ਦਿਖਾਉਂਦਾ ਹੈ ਜੋ ਸਿਰਫ਼ ਟਨਲ ਦੇ ਅੰਦਰ ਹੀ ਕਦੇ ਸੀ, ਆਮ ਤੌਰ ’ਤੇ ਸੂਚੀ ਵਿੱਚ ਪਹਿਲਾ। ਉਹ ਲਾਈਨ ਹਟਾਉਣ ਨਾਲ ਲਗਭਗ ਦਸ ਮਿੰਟ ਲਈ ਠੀਕ ਹੋਇਆ ਜਾਪਦਾ ਹੈ, ਜਦ ਤੱਕ ਸਸਪੈਂਡ, Wi-Fi ਰੋਮਿੰਗ ਜਾਂ ਰੀਸਟਾਰਟ ਉਸ ਨੂੰ ਵਾਪਸ ਨਹੀਂ ਲੈ ਆਉਂਦਾ। ਤੁਹਾਡੀ ਸੋਧੀ ਫਾਈਲ ਸੈਟਿੰਗ ਨਹੀਂ ਹੈ; ਇਹ ਲਿੰਕ ਸਥਿਤੀ ਦੀ ਪੇਸ਼ਕਾਰੀ ਹੈ ਜੋ ਕਿਸੇ ਹੋਰ ਹਿੱਸੇ ਦੀ ਮਲਕੀਅਤ ਹੈ।

ਇੱਕ ਪੁਰਾਣੀ ਐਂਟਰੀ ਹਰ ਖੋਜ ’ਤੇ ਸਕਿੰਟ ਕਿਉਂ ਖਰਚ ਕਰਦੀ ਹੈ

glibc ਰਿਜ਼ੌਲਵਰ ਨੇਮਸਰਵਰ ਸੂਚੀ ਨੂੰ ਕ੍ਰਮ ਵਿੱਚ ਚੱਲਦਾ ਹੈ ਅਤੇ ਅਗਲਾ ਅਜ਼ਮਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਟਾਈਮਆਉਟ ਪੂਰਾ ਹੋਣ ਦੀ ਉਡੀਕ ਕਰਦਾ ਹੈ, ਅਤੇ resolv.conf(5) ਉਸ ਸੂਚੀ ਨੂੰ ਤਿੰਨ ਐਂਟਰੀਆਂ ਤੱਕ ਸੀਮਿਤ ਕਰਦਾ ਹੈ। ਟਨਲ ਜਾਣ ਤੋਂ ਬਾਅਦ 10.8.0.1 ਵਰਗਾ ਟਨਲ-ਪਾਸੇ ਦਾ ਰਿਜ਼ੌਲਵਰ ਸੂਚੀ ਦੇ ਸਿਖਰ ’ਤੇ ਰੱਖੋ, ਤਾਂ ਹਰ ਖੋਜ ਜਵਾਬ ਦੇਣ ਵਾਲੇ ਸਰਵਰ ਤੱਕ ਪਹੁੰਚਣ ਤੋਂ ਪਹਿਲਾਂ ਟਾਈਮਆਉਟ ਦੀ ਕੀਮਤ ਦਿੰਦੀ ਹੈ। ਲੱਛਣ DNS ਗਲਤੀ ਦੀ ਬਜਾਏ ਮਰੀ ਕਨੈਕਸ਼ਨ ਵਰਗਾ ਦਿਸਣ ਦਾ ਇਹੀ ਕਾਰਨ ਹੈ: ਬ੍ਰਾਊਜ਼ਰ ਬਲਾਕ ਹੁੰਦੇ ਹਨ, ਸਮਾਂ ਖਤਮ ਹੁੰਦਾ ਹੈ ਅਤੇ ਕਈ ਵਾਰ ਬਾਅਦ ਵਿੱਚ ਪੁਰਾਣਾ ਹੋ ਜਾਣ ਵਾਲਾ ਕੈਸ਼ ਕੀਤਾ ਪਤਾ ਦਿੰਦੇ ਹਨ।

«ਇੰਟਰਨੈੱਟ ਖਰਾਬ ਹੋ ਗਿਆ» ਵਜੋਂ ਸ਼ਿਕਾਇਤ ਆਉਣ ਦਾ ਕਾਰਨ ਵੀ ਇਹੀ ਹੈ। IP ਪਤੇ ’ਤੇ ping ਲਿੰਕ ਠੀਕ ਹੋਣ ਦਾ ਸਬੂਤ ਦਿੰਦਾ ਹੈ, ਜਿਸ ਨਾਲ ਖਰਾਬੀ ਐਪ ਦੀ ਜਾਪਦੀ ਹੈ। ਰਿਜ਼ੌਲਵਰ ਸੂਚੀ ਪਹਿਲੀ ਚੀਜ਼ ਹੈ ਜੋ ਪੜ੍ਹਨੀ ਚਾਹੀਦੀ ਹੈ ਅਤੇ ਆਖਰੀ ਜੋ ਸੋਧਣੀ ਚਾਹੀਦੀ ਹੈ।

ਭਰਮ: resolv.conf ਇੱਕ ਸੈਟਿੰਗ ਫਾਈਲ ਹੈ

ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ ਪੁੱਛੋ ਕਿ ਇਹ ਰਾਹ ਅਸਲ ਵਿੱਚ ਕੀ ਹੈ:

ls -l /etc/resolv.conf
readlink -f /etc/resolv.conf

systemd-resolved ਵਾਲੇ ਹੋਸਟ ’ਤੇ ਇਹ 127.0.0.53 ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਨ ਵਾਲੀ ਸਟਬ ਫਾਈਲ ਦਾ ਸਿੰਬੋਲਿਕ ਲਿੰਕ ਹੈ, ਅਤੇ ਅਸਲ ਸਰਵਰ resolvectl ਜੋ ਛਾਪਦਾ ਹੈ ਉਸ ਪ੍ਰਤੀ-ਲਿੰਕ ਸਥਿਤੀ ਵਿੱਚ ਰਹਿੰਦੇ ਹਨ। NetworkManager ਵਾਲੇ ਹੋਸਟ ’ਤੇ ਇਹ NetworkManager ਵੱਲੋਂ ਸਰਗਰਮ ਕਨੈਕਸ਼ਨ ਤੋਂ ਲਿਖੀ ਫਾਈਲ ਹੋ ਸਕਦੀ ਹੈ। ਕੁਝ ਵਿਕਰੇਤਾ ਕਲਾਇੰਟਾਂ ਵਿੱਚ ਇਹ ਸਾਧਾਰਨ ਫਾਈਲ ਹੈ ਜੋ ਜੁੜਦੇ ਸਮੇਂ ਉੱਥੇ ਹੀ ਮੁੜ ਲਿਖੀ ਜਾਂਦੀ ਹੈ ਅਤੇ, ਜੇ ਤੁਸੀਂ ਭਾਗਸ਼ਾਲੀ ਨਹੀਂ, ਡਿਸਕਨੈਕਟ ਹੁੰਦੇ ਸਮੇਂ ਕਦੇ ਬਹਾਲ ਨਹੀਂ ਹੁੰਦੀ। ਇਹ ਤਿੰਨ ਵੱਖਰੇ ਮਾਲਕ ਹਨ, ਅਤੇ ਪਹਿਲੀਆਂ ਦੋ ਨੂੰ ਹੱਥ ਨਾਲ ਸੋਧਣਾ ਜਾਂ ਤਾਂ ਕੁਝ ਨਹੀਂ ਕਰਦਾ ਜਾਂ ਅਗਲੀ ਨੈੱਟਵਰਕ ਘਟਨਾ ਤੱਕ ਰਹਿੰਦਾ ਹੈ।

resolvectl status ਉਹ ਨਜ਼ਾਰਾ ਹੈ ਜੋ ਸੱਚ ਕਹਿੰਦਾ ਹੈ: ਪ੍ਰਤੀ-ਲਿੰਕ DNS ਸਰਵਰ, ਰੂਟਿੰਗ ਡੋਮੇਨ, ਅਤੇ ਕੀ ਟਨਲ ਲਿੰਕ ਅਜੇ ਵੀ ਹੈ। resolvectl query example.com ਹੋਰ ਅੱਗੇ ਜਾ ਕੇ ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਕਿਹੜੇ ਇੰਟਰਫੇਸ ਨੇ ਜਵਾਬ ਦਿੱਤਾ। ਫਾਈਲ ਛੂਹਣ ਤੋਂ ਪਹਿਲਾਂ ਦੋਵੇਂ ਵਰਤੋ, ਅਤੇ ਯਾਦ ਰੱਖੋ ਕਿ ਆਪਣਾ ਸੁਰੱਖਿਅਤ DNS ਵਾਲਾ ਬ੍ਰਾਊਜ਼ਰ ਇਹ ਸਭ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰਦਾ ਹੈ।

ਕੁਝ ਵੀ ਸੋਧਣ ਤੋਂ ਪਹਿਲਾਂ ਮਾਲਕ ਲੱਭੋ

ਆਮ ਤੌਰ ’ਤੇ ਤਿੰਨ ਹਿੱਸੇ ਇੱਕੋ ਸੈਟਿੰਗ ਲਈ ਮੁਕਾਬਲਾ ਕਰਦੇ ਹਨ: systemd-resolved, NetworkManager ਅਤੇ ਜੋ VPN ਕਲਾਇੰਟ ਨੇ ਸਥਾਪਿਤ ਕੀਤਾ। ਪਹਿਲਾਂ ਜੀਵਿਤ ਦੀ ਪਛਾਣ ਕਰੋ:

systemctl is-active systemd-resolved
nmcli connection show --active
ps aux | grep -E "openvpn|wg-quick|vpn"

ਜੇ resolved ਸਰਗਰਮ ਹੈ ਅਤੇ ਸਿੰਬੋਲਿਕ ਲਿੰਕ ਉਸ ਦੇ ਸਟਬ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦਾ ਹੈ, ਤਾਂ ਗਲੋਬਲ ਫਾਈਲ ਤਿਆਰ ਆਉਟਪੁੱਟ ਹੈ ਅਤੇ ਤੁਹਾਡੀ ਸੋਧ ਸਿਰਫ਼ ਦਿੱਖੀ ਹੈ। ਜੇ NetworkManager ਕਨੈਕਸ਼ਨ ਦਾ ਮਾਲਕ ਹੈ, ਸਰਵਰ ਕਨੈਕਸ਼ਨ ਪ੍ਰੋਫਾਈਲ ਦੇ ਹਨ, ਇਸ ਲਈ ਸੁਧਾਰ ਫਾਈਲ ਸੋਧ ਨਹੀਂ ਸਗੋਂ nmcli ਵਿਸ਼ੇਸ਼ਤਾ ਬਦਲਾਅ ਹੈ। ਜੇ ਵਿਕਰੇਤਾ ਦਾ ਡੀਮਨ ਚੱਲ ਰਿਹਾ ਹੈ, ਤਾਂ ਸਿਰਫ਼ ਉਸਦਾ ਆਪਣਾ ਬਹਾਲੀ ਰਾਹ ਹੀ ਅਗਲੇ ਕਨੈਕਸ਼ਨ ਤੱਕ ਬਚਦਾ ਹੈ।

ਕਲਾਇੰਟ ਵੱਲੋਂ ਛੱਡੀ ਲਿੰਕ ਸਥਿਤੀ ਸਾਫ਼ ਕਰੋ

ਮਾਰਿਆ ਗਿਆ ਕਲਾਇੰਟ ਆਪਣਾ ਕਲੀਨਅੱਪ ਹੁੱਕ ਨਹੀਂ ਚਲਾ ਸਕਦਾ। SIGKILL ਬਿਲਕੁਲ ਫੜਿਆ ਨਹੀਂ ਜਾ ਸਕਦਾ, ਜਦਕਿ SIGINT ਅਤੇ SIGTERM ਫੜੇ ਜਾ ਸਕਦੇ ਹਨ, ਇਸ ਲਈ ਜ਼ਬਰਦਸਤੀ ਮਾਰਨ ਤੋਂ ਬਾਅਦ «ਬੱਸ ਰੁਕ ਗਈ» ਟਨਲ ਅਕਸਰ ਇੰਟਰਫੇਸ ਰਜਿਸਟਰੇਸ਼ਨ ਅਤੇ ਰਿਜ਼ੌਲਵਰ ਐਂਟਰੀ ਦੋਵੇਂ ਉੱਥੇ ਹੀ ਛੱਡ ਦਿੰਦੀ ਹੈ। ਖਾਸ PID ਲੱਭੋ ਅਤੇ ਸਿਗਨਲ ਸਿਰਫ਼ ਉਸੇ ਨੂੰ ਭੇਜੋ:

ps aux | grep -E "openvpn|wg-quick"
sudo kill <pid>
resolvectl revert tun0

ਪੂਰੀ ਮਿਲਾਨ ਸੂਚੀ ਪੜ੍ਹਨ ਤੋਂ ਪਹਿਲਾਂ pkill -f vpn ਜਾਂ killall vpn ਵੱਲ ਹੱਥ ਨਾ ਵਧਾਓ। -f ਪੂਰੀ ਕਮਾਂਡ ਲਾਈਨ ਨਾਲ ਮਿਲਦਾ ਹੈ, ਇਸ ਲਈ ਇਹ ਰੈਪਰ ਸਕ੍ਰਿਪਟ, ਐਡੀਟਰ ਸੈਸ਼ਨ ਜਾਂ ਅਜਿਹੀ ਅਸੰਬੰਧਿਤ ਪ੍ਰਕਿਰਿਆ ਖਤਮ ਕਰ ਸਕਦਾ ਹੈ ਜਿਸ ਦੇ ਰਾਹ ਵਿੱਚ ਉਹ ਸਟਰਿੰਗ ਹੈ। ਕੰਮ ਵਿਚਕਾਰ ਗਲਤ ਪ੍ਰਕਿਰਿਆ ਖਤਮ ਕਰਨਾ ਹੀ ਉਹ ਤਰੀਕਾ ਹੈ ਜਿਸ ਨਾਲ ਰਿਜ਼ੌਲਵਰ ਸਮੱਸਿਆ ਗੁੰਮ ਫਾਈਲ ਬਣ ਜਾਂਦੀ ਹੈ।

resolvectl revert ਉਸ ਲਿੰਕ ਦੀ ਰਨਟਾਈਮ DNS ਸੰਰਚਨਾ ਰੀਸੈਟ ਕਰਦਾ ਹੈ, ਜੋ ਰਿਜ਼ੌਲਵਰ ਰੀਸਟਾਰਟ ਕਰਨ ਤੋਂ ਸੰਕੀਰਣ ਅਤੇ ਗਲੋਬਲ ਫਾਈਲ ਸੋਧਣ ਤੋਂ ਬਹੁਤ ਸੰਕੀਰਣ ਹੈ। ਜੇ ਟਨਲ ਲਿੰਕ ਪੂਰੀ ਤਰ੍ਹਾਂ ਚਲਾ ਗਿਆ ਹੈ, ਤਾਂ systemctl restart NetworkManager ਕਨੈਕਸ਼ਨ ਸਥਿਤੀ ਮੁੜ ਬਣਾਉਂਦਾ ਹੈ ਅਤੇ ਸਰੋਤ ਥ੍ਰੈਡ ਵਾਰ-ਵਾਰ ਇਸੇ ਕਦਮ ’ਤੇ ਵਾਪਸ ਆਉਂਦੇ ਹਨ। Restart=always ਵਾਲੇ ਸੇਵਾ ਮੈਨੇਜਰ ਤੋਂ ਸਾਵਧਾਨ ਰਹੋ, ਕਿਉਂਕਿ ਇਹ ਮਾਰੇ ਗਏ ਕਲਾਇੰਟ ਅਤੇ ਉਸ ਦੀਆਂ DNS ਸੈਟਿੰਗਾਂ ਨੂੰ ਸਿੱਧਾ ਵਾਪਸ ਰੱਖ ਸਕਦਾ ਹੈ।

ਦੂਜੀ ਦਿਸ਼ਾ: ਧੱਕਿਆ ਗਿਆ ਪਰ ਕਦੇ ਨਾ ਪਹੁੰਚਿਆ DNS

ਪੁਰਾਣੀ ਐਂਟਰੀ ਦਾ ਸ਼ੀਸ਼ਾ-ਬਿੰਬ ਉਹ ਟਨਲ ਹੈ ਜਿਸ ਵਿੱਚ ਕੋਈ ਵੀ ਕੰਮਕਾਜੀ ਰਿਜ਼ੌਲਵਰ ਨਹੀਂ। ਪ੍ਰੋਫਾਈਲ ਵਿੱਚ DNS ਚੋਣ ਇੱਕ ਬੇਨਤੀ ਹੈ; ਕਨੈਕਸ਼ਨ ਸੰਭਾਲਣ ਵਾਲੇ ਹਿੱਸੇ ਨੂੰ ਇਹ ਰਿਜ਼ੌਲਵਰ ਨੂੰ ਸੌਂਪਣੀ ਪੈਂਦੀ ਹੈ। ਜੇ ਲਾਗ ਦਿਖਾਉਂਦੀ ਹੈ ਕਿ ਸਰਵਰ ਮਿਲਿਆ ਪਰ ਟਨਲ ਲਿੰਕ ਕੋਈ DNS ਸੈਟਿੰਗ ਨਹੀਂ ਲੈ ਕੇ ਚੱਲਦਾ, ਤਾਂ ਗੁੰਮ ਇੰਟੀਗ੍ਰੇਸ਼ਨ ਹੈ, ਸਰਵਰ ਨਹੀਂ।

ਸੌਂਪਣ ਦੀ ਜਾਂਚ ਹੱਥ ਨਾਲ ਕਰੋ, ਇਹ «ਸਰਵਰ ਗਲਤ ਹੈ» ਅਤੇ «ਕਿਸੇ ਨੇ ਲਾਗੂ ਨਹੀਂ ਕੀਤਾ» ਨੂੰ ਵੱਖ ਕਰਦਾ ਹੈ:

resolvectl dns tun0 10.10.10.10
resolvectl domain tun0 ~.

ਸਭ ਫੜਨ ਵਾਲਾ ਰੂਟਿੰਗ ਡੋਮੇਨ ਹਰ ਨਾਮ ਉਸ ਲਿੰਕ ’ਤੇ ਭੇਜਦਾ ਹੈ, ਜੋ ਪੂਰਨ-ਟਨਲ ਕਲਾਇੰਟ ਚਾਹੁੰਦਾ ਹੈ ਅਤੇ ਜੋ ਵੰਡਿਆ DNS ਵਰਤਣਾ ਨਹੀਂ ਚਾਹੀਦਾ। ਇਹ ਸੈਟਿੰਗਾਂ ਅਗਲੇ ਕਨੈਕਸ਼ਨ ’ਤੇ ਗਾਇਬ ਹੋ ਜਾਂਦੀਆਂ ਹਨ। NetworkManager ਵਿੱਚ ਇਹਨਾਂ ਨੂੰ ਪੱਕੀਆਂ ਬਣਾਉਣ ਲਈ ਆਟੋਮੈਟਿਕ DNS ਬੰਦ ਕਰੋ, ਕਨੈਕਸ਼ਨ ’ਤੇ ਸਰਵਰ ਸੈਟ ਕਰੋ ਅਤੇ ਡੋਮੇਨ ਜੋੜੋ:

nmcli connection modify office ipv4.ignore-auto-dns yes
nmcli connection modify office ipv4.dns 10.10.10.10
nmcli connection modify office ipv4.dns-search "~."

ਅਜਿਹੀ ਕੰਪਨੀ ਟਨਲ ਲਈ ਜਿਸ ਨੂੰ ਸਿਰਫ਼ ਅੰਦਰੂਨੀ ਨਾਵਾਂ ਦਾ ਜਵਾਬ ਦੇਣਾ ਚਾਹੀਦਾ ਹੈ, ਉਹ ਜ਼ੋਨ ਸਭ ਫੜਨ ਦੀ ਬਜਾਏ ਸ਼ੁਰੂਆਤੀ ਟਿਲਡੇ ਨਾਲ ਸੂਚੀਬੱਧ ਕਰੋ, ਤਾਂ ਜੋ ਜਨਤਕ ਨਾਮ ਸਥਾਨਕ ਰਿਜ਼ੌਲਵਰ ਵਰਤਦੇ ਰਹਿਣ।

ਅਗਲੀ ਰੁਕਾਵਟ ਬਣਨ ਵਾਲੇ ਵਰਕਅਰਾਊਂਡ

ਜੁੜਨ ਤੋਂ ਪਹਿਲਾਂ resolv.conf ਦੀ ਨਕਲ ਲੈਣਾ ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਬਹਾਲ ਕਰਨਾ runbook ਵਿੱਚ ਜਾਇਜ਼ ਲਾਈਨ ਹੈ, ਅਤੇ ਇਹ ਮੁਰੰਮਤ ਨਹੀਂ ਸਗੋਂ ਵਰਕਅਰਾਊਂਡ ਹੈ। ਇਹ ਠੀਕ ਤਦ ਫੇਲ੍ਹ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਇਸ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ, ਕਿਉਂਕਿ ਕਰੈਸ਼ ਜਾਂ ਜ਼ਬਰਦਸਤੀ ਰੀਬੂਟ ਬਹਾਲੀ ਛੱਡ ਦਿੰਦਾ ਹੈ। ਇਸ ਨੂੰ ਵਰਕਅਰਾਊਂਡ ਵਜੋਂ ਲਿਖੋ ਤਾਂ ਜੋ ਅਗਲਾ ਵਿਅਕਤੀ ਇਸ ’ਤੇ ਨਾ ਬਣਾਏ।

systemd-resolved ਬੰਦ ਕਰਨਾ ਅਤੇ ਜਨਤਕ ਸਰਵਰ ਹਾਰਡਕੋਡ ਕਰਨਾ ਦੂਜਾ ਪ੍ਰਸਿੱਧ ਕਦਮ ਹੈ। ਇਹ ਜੁੜਨ ਅਤੇ ਡਿਸਕਨੈਕਟ ਨੂੰ ਅਨੁਮਾਨਯੋਗ ਬਣਾਉਂਦਾ ਹੈ ਅਤੇ ਹਰ ਹੋਰ ਨੈੱਟਵਰਕ ਲਈ ਪ੍ਰਤੀ-ਲਿੰਕ DNS ਹਟਾ ਦਿੰਦਾ ਹੈ, ਜੋ ਅੰਦਰੂਨੀ ਨਾਵਾਂ ਲਈ ਵੰਡਿਆ DNS ਤੋੜਦਾ ਹੈ ਅਤੇ ਸਵਾਲਾਂ ਨੂੰ ਅੰਦਰ ਰੱਖਣ ਲਈ ਬਣਾਈ ਟਨਲ ਦਾ ਮਕਸਦ ਫੇਲ੍ਹ ਕਰਦਾ ਹੈ। resolvconf ਸਥਾਪਿਤ ਕਰਨਾ ਅਤੇ ਜਨਤਕ ਸਰਵਰ ਪਿੰਨ ਕਰਨਾ ਵਾਧੂ ਪਰਤ ਨਾਲ ਉਹੀ ਖਰਚ ਹੈ। ਇਹਨਾਂ ਵਿੱਚੋਂ ਕਿਸੇ ਨੂੰ ਵੀ ਨਿਦਾਨ ਮੰਨੋ: ਜੇ ਇਹ ਬ੍ਰਾਊਜ਼ਿੰਗ ਵਾਪਸ ਲਿਆਉਂਦਾ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਸਿੱਖਿਆ ਕਿ ਰਿਜ਼ੌਲਵਰ ਇੰਟੀਗ੍ਰੇਸ਼ਨ ਦੋਸ਼ੀ ਹੈ, ਇਹ ਨਹੀਂ ਕਿ ਜਨਤਕ ਸਰਵਰ ਸਹੀ ਹਨ।

ਟਿਕਾਊ ਸੁਧਾਰ ਹਰ ਪਰਤ ਲਈ ਇੱਕ ਮਾਲਕ ਹੈ: ਫੈਸਲਾ ਕਰੋ ਕਿ ਟਨਲ ਲਿੰਕ ਦਾ DNS ਕਿਹੜੇ ਹਿੱਸੇ ਦਾ ਹੈ ਅਤੇ ਗਲੋਬਲ ਡਿਫਾਲਟ ਕਿਸਦਾ, ਇਹ ਲਿਖੋ ਅਤੇ ਬਾਕੀਆਂ ਨੂੰ ਰਾਹ ਵਿੱਚੋਂ ਹਟਾਓ। ਫਿਰ ਡਿਸਕਨੈਕਟ ਤੋਂ ਬਾਅਦ ਉਸ ਨਾਮ ਨਾਲ ਜਾਂਚੋ ਜੋ ਸਿਰਫ਼ VPN ਹੱਲ ਕਰਦਾ ਹੈ। ਜੇ ਨਿੱਜੀ ਨਾਮ ਅਜੇ ਵੀ ਜਵਾਬ ਦਿੰਦਾ ਹੈ, ਤਾਂ ਰਜਿਸਟ੍ਰੇਸ਼ਨ ਹਟਾਈ ਨਹੀਂ ਗਈ; ਜੇ ਕੁਝ ਵੀ ਹੱਲ ਨਹੀਂ ਹੁੰਦਾ, ਤਾਂ ਫਾਈਲ ਉਸ ਸਰਵਰ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦੀ ਹੈ ਜੋ ਹੁਣ ਨਹੀਂ ਹੈ। ਦੋਵੇਂ ਬ੍ਰਾਊਜ਼ਰ ਖੋਲ੍ਹਣ ਤੋਂ ਪਹਿਲਾਂ resolvectl ਵਿੱਚ ਦਿਸਦੇ ਹਨ।