VPN ਜੁੜਨ ਤੋਂ ਬਾਅਦ ਵੀ Pi-hole ਇਸ਼ਤਿਹਾਰ ਬਲੌਕ ਨਹੀਂ ਕਰ ਰਿਹਾ: ਪੰਜ ਜਾਂਚਾਂ

ਇੱਕ ਕਲਾਇੰਟ 'ਤੇ ਅਜੇ ਵੀ ਇਸ਼ਤਿਹਾਰ ਦਿਸ ਰਹੇ ਹਨ, Pi-hole ਆਪਣੇ ਆਪ ਨੂੰ ਸਿਹਤਮੰਦ ਦੱਸ ਰਿਹਾ ਹੈ, ਅਤੇ ਟਨਲ ਚਾਲੂ ਹੈ, ਇਸ ਲਈ ਉਸ ਕਲਾਇੰਟ ਦੀ ਟ੍ਰੈਫਿਕ Pi ਰਾਹੀਂ ਭੇਜਣ ਦੀ ਸੁਭਾਵਿਕ ਪ੍ਰਵਿਰਤੀ ਹੁੰਦੀ ਹੈ। ਇਹ ਗਲਤ ਮੋੜ ਹੈ। ਫਿਲਟਰਿੰਗ ਲਈ ਪੈਕੇਟ ਨਹੀਂ, ਸਵਾਲ ਚਾਹੀਦੇ ਹਨ, ਅਤੇ ਜਿਸ ਕਲਾਇੰਟ ਦੀਆਂ ਕੁਇਰੀਆਂ ISP ਦੇ ਰਿਜ਼ੋਲਵਰ ਕੋਲ ਜਾਂਦੀਆਂ ਹਨ, ਉਸ ਦੀ ਟ੍ਰੈਫਿਕ ਕਿੱਥੇ ਵੀ ਵਹੇ, ਉਹ ਅਫਿਲਟਰ ਹੀ ਰਹਿੰਦੀ ਹੈ। ਇਹ ਸੂਚੀ ਕ੍ਰਮ ਵਿੱਚ ਪੂਰੀ ਕਰੋ ਅਤੇ ਅਸਫਲ ਹੋਣ ਵਾਲੇ ਪਹਿਲੇ ਕਦਮ 'ਤੇ ਹੀ ਰੁਕੋ, ਕਿਉਂਕਿ ਪਿਛਲਾ ਕਦਮ ਟੁੱਟਿਆ ਹੋਣ ਵੇਲੇ ਅਗਲਾ ਕਦਮ ਤੁਹਾਨੂੰ ਕੁਝ ਨਹੀਂ ਦੱਸ ਸਕਦਾ।

1. ਕਲਾਇੰਟ ਅਸਲ ਵਿੱਚ ਜੋ ਰਿਜ਼ੋਲਵਰ ਵਰਤ ਰਿਹਾ ਹੈ ਉਹ ਪੜ੍ਹੋ

ਰਾਊਟਰ ਨੂੰ ਨਹੀਂ, ਕਲਾਇੰਟ ਨੂੰ ਪੁੱਛੋ। Linux 'ਤੇ resolvectl status ਹਰ ਲਿੰਕ ਦੇ DNS ਸਰਵਰ ਅਤੇ ਕਿਹੜਾ ਲਿੰਕ ਜਿੱਤਦਾ ਹੈ ਛਾਪਦਾ ਹੈ; ਇਕੱਲਾ /etc/resolv.conf ਆਮ ਤੌਰ 'ਤੇ 127.0.0.53 ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਨ ਵਾਲਾ ਸਟਬ ਹੁੰਦਾ ਹੈ। Windows 'ਤੇ ipconfig /all ਹਰ ਅਡੈਪਟਰ ਲਈ DHCP ਵੱਲੋਂ ਦਿੱਤੇ ਸਰਵਰ ਸੂਚੀਬੱਧ ਕਰਦਾ ਹੈ, ਅਤੇ macOS 'ਤੇ scutil --dns ਉਹੀ ਗੱਲ ਸਕੋਪ ਅਨੁਸਾਰ ਦਿਖਾਉਂਦਾ ਹੈ। ਜੇ ਜਵਾਬ Pi-hole ਦਾ ਪਤਾ ਨਹੀਂ ਹੈ, ਤਾਂ ਤੁਹਾਡੇ ਕੋਲ ਅਸਾਈਨਮੈਂਟ ਦੀ ਸਮੱਸਿਆ ਹੈ ਅਤੇ ਕਦਮ 2 ਉਹੀ ਥਾਂ ਹੈ ਜਿੱਥੇ ਇਹ ਰਹਿੰਦੀ ਹੈ।

ਸਿਸਟਮ ਰਿਜ਼ੋਲਵਰ ਸਹੀ ਸੈੱਟ ਹੋਣ 'ਤੇ ਵੀ ਦੋ ਚੀਜ਼ਾਂ ਉਸ ਨੂੰ ਹਰਾਉਂਦੀਆਂ ਹਨ। ਆਪਣੇ ਸੁਰੱਖਿਅਤ DNS ਵਾਲੇ ਬ੍ਰਾਊਜ਼ਰ (Chrome ਦਾ “Use secure DNS”, Firefox ਦਾ network.trr.mode) HTTPS ਰਾਹੀਂ ਜਨਤਕ ਰਿਜ਼ੋਲਵਰ ਨੂੰ ਕੁਇਰੀਆਂ ਭੇਜਦੇ ਹਨ ਅਤੇ ਪੋਰਟ 53 ਕਦੇ ਨਹੀਂ ਖੋਲ੍ਹਦੇ। ਅਤੇ ਕਲਾਇੰਟ 'ਤੇ ਹੀ ਮੌਜੂਦ VPN ਕਲਾਇੰਟ ਆਪਣੇ ਟਨਲ ਇੰਟਰਫੇਸ 'ਤੇ ~. ਰਾਊਟਿੰਗ ਡੋਮੇਨ ਨਾਲ DNS ਸਰਵਰ ਸਥਾਪਿਤ ਕਰ ਸਕਦਾ ਹੈ, ਜੋ ਉਸ ਲਿੰਕ ਨੂੰ ਹਰ ਨਾਮ ਲਈ ਅਧਿਕਾਰਤ ਬਣਾ ਦਿੰਦਾ ਹੈ।

ਐਪਲੀਕੇਸ਼ਨ ਜੋ ਰਾਹ ਲੈਂਦੇ ਹਨ ਉਹ ਪਰਖੋ, ਡੀਬੱਗ ਟੂਲ ਜੋ ਰਾਹ ਲੈਂਦਾ ਹੈ ਉਹ ਨਹੀਂ। resolvectl query example.com ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਕਿਹੜੇ ਲਿੰਕ ਨੇ ਜਵਾਬ ਦਿੱਤਾ, ਅਤੇ getent hosts example.com ਐਪਲੀਕੇਸ਼ਨ ਵਾਲੇ ਹੀ NSS ਰਾਹ ਤੋਂ ਜਾਂਦਾ ਹੈ; macOS 'ਤੇ dscacheutil -q host -a name example.com ਉਹ ਸਕੋਪਡ ਰਿਜ਼ੋਲਵਰ ਪੜ੍ਹਦਾ ਹੈ ਜੋ scutil --dns ਸੂਚੀਬੱਧ ਕਰਦਾ ਹੈ। ਨਿਰੋਲ dig ਇਹ ਨਹੀਂ ਕਰਦਾ: ਇਹ /etc/resolv.conf ਪੜ੍ਹਦਾ ਹੈ ਅਤੇ ਪ੍ਰਤੀ-ਲਿੰਕ ਚੋਣ ਛੱਡ ਦਿੰਦਾ ਹੈ, ਇਸ ਲਈ ਜਦੋਂ ਹਰ ਐਪਲੀਕੇਸ਼ਨ ਪੁਸ਼ ਕੀਤਾ ਰਿਜ਼ੋਲਵਰ ਵਰਤ ਰਹੀ ਹੋਵੇ ਤਾਂ ਇਹ Pi-hole ਤੋਂ ਜਵਾਬ ਦੇ ਸਕਦਾ ਹੈ, ਅਤੇ ਇਹੀ ਉਹ ਸਹੀ ਖਰਾਬੀ ਹੈ ਜਿਸ ਲਈ ਇਹ ਸੂਚੀ ਹੈ। ਇੱਕ ਖਾਸ ਸਰਵਰ ਪਰਖਣ ਲਈ dig @192.168.1.53 ਰੱਖੋ।

2. ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਜਵਾਬ ਕੌਣ ਵੰਡਦਾ ਹੈ

ਅਸਾਈਨਮੈਂਟ ਉਸੇ ਤੋਂ ਆਉਂਦੀ ਹੈ ਜੋ DHCP ਨੂੰ ਜਵਾਬ ਦਿੰਦਾ ਹੈ। dnsmasq 'ਤੇ ਇਹ ਇੱਕ ਲਾਈਨ ਹੈ, dhcp-option=6,192.168.1.53; ਰਾਊਟਰ ਦੇ ਵੈੱਬ UI ਵਿੱਚ ਇਹ LAN DHCP ਭਾਗ ਦਾ DNS ਫੀਲਡ ਹੈ। ਕਲਾਇੰਟਾਂ ਨੂੰ ਇਹ ਵੇਖਣ ਤੋਂ ਪਹਿਲਾਂ ਨਵੀਨੀਕਰਨ ਕਰਨਾ ਪੈਂਦਾ ਹੈ। ਦਿਨਾਂ ਤੋਂ ਚੱਲ ਰਿਹਾ ਯੰਤਰ ਅਜੇ ਵੀ ਪੁਰਾਣਾ ਲੀਜ਼ ਰੱਖਦਾ ਹੈ, ਅਤੇ ਹੱਥ ਨਾਲ ਲਿਖਿਆ ਰਿਜ਼ੋਲਵਰ ਵਾਲਾ ਯੰਤਰ ਉਹ ਹਮੇਸ਼ਾ ਰੱਖਦਾ ਹੈ। ਪ੍ਰਸਾਰ ਮੰਨਣ ਦੀ ਥਾਂ ਟੈਸਟ ਕਲਾਇੰਟ 'ਤੇ ਨਵੀਨੀਕਰਨ ਕਰੋ।

IPv6 ਉਹ ਅੱਧ ਹੈ ਜੋ ਖੁੰਝ ਜਾਂਦਾ ਹੈ। ਰਾਊਟਰ ਘੋਸ਼ਣਾਵਾਂ ਆਪਣਾ DNS ਸਰਵਰ ਲੈ ਕੇ ਆ ਸਕਦੀਆਂ ਹਨ (RDNSS), ਅਤੇ OpenWrt 'ਤੇ ਇਹ odhcpd ਦਾ ra_dns ਵਿਕਲਪ ਹੈ; ਜੋ ਕਲਾਇੰਟ IPv6 ਪਸੰਦ ਕਰਦਾ ਹੈ ਉਹ ਉਸ ਸਰਵਰ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ ਜਦੋਂ ਕਿ ਹੁਣੇ ਸੈੱਟ ਕੀਤਾ DHCPv4 ਵਿਕਲਪ ਵਰਤਿਆ ਨਹੀਂ ਜਾਂਦਾ। ਜੇ ਤੁਸੀਂ IPv6 DNS ਦੇਣ ਲਈ ਤਿਆਰ ਨਹੀਂ ਹੋ, ਤਾਂ ਸਿਰਫ਼ DNS ਘੋਸ਼ਣਾ ਸਾਫ਼ ਕਰੋ: odhcpd ਵਿੱਚ ra_dns, ਜਾਂ ਰਾਊਟਰ ਘੋਸ਼ਣਾਵਾਂ ਨੂੰ ਜਵਾਬ ਦੇਣ ਵਾਲੀ ਕਿਸੇ ਵੀ ਚੀਜ਼ ਵਿੱਚ RDNSS ਵਿਕਲਪ। ਪੂਰੀ ਘੋਸ਼ਣਾ ਬੰਦ ਕਰਨ ਨਾਲ LAN ਤੋਂ IPv6 ਐਡਰੈਸਿੰਗ ਵੀ ਹਟ ਜਾਂਦੀ ਹੈ, ਜੋ ਤੁਹਾਡੇ ਇਰਾਦੇ ਨਾਲੋਂ ਕਿਤੇ ਵੱਡੀ ਤਬਦੀਲੀ ਹੈ, ਜਦੋਂ ਕਿ ਸਿਰਫ਼ DNS ਵਿਕਲਪ ਸਾਫ਼ ਕਰਨ ਨਾਲ ਐਡਰੈਸਿੰਗ ਅਟੁੱਟ ਰਹਿੰਦੀ ਹੈ ਅਤੇ ਗੁੰਮ RDNSS ਪੈਕੇਟ ਕੈਪਚਰ ਵਿੱਚ ਦਿਸਦਾ ਹੈ।

3. ਸਾਬਤ ਕਰੋ ਕਿ ਕੁਇਰੀ Pi-hole ਤੱਕ ਪਹੁੰਚਦੀ ਹੈ

Pi ਤੋਂ ਕੀਤੀ ਕੁਇਰੀ ਨੈੱਟਵਰਕ ਰਾਹ ਬਾਰੇ ਕੁਝ ਸਾਬਤ ਨਹੀਂ ਕਰਦੀ। ਇਸ ਨੂੰ ਕਲਾਇੰਟ ਤੋਂ ਚਲਾਓ ਅਤੇ ਜਵਾਬ ਕੋਡ ਪੜ੍ਹੋ:

dig @192.168.1.53 example.com
dig @192.168.1.53 doubleclick.net

ਟਾਈਮਆਊਟ ਫਿਲਟਰਿੰਗ ਜਾਂ ਰੂਟ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦਾ ਹੈ; REFUSED ਪਹੁੰਚ ਨਿਯਮ ਵੱਲ; SERVFAIL Pi-hole ਪਿੱਛੇ ਵਾਲੇ ਅੱਪਸਟ੍ਰੀਮ ਰਿਜ਼ੋਲਵਰ ਵੱਲ; ਕੁਇਰੀ ਲੌਗ ਵਿੱਚ ਕਦੇ ਨਾ ਦਿਸਣ ਵਾਲਾ ਸਹੀ ਜਵਾਬ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਕਲਾਇੰਟ ਨੇ ਕੁਝ ਹੋਰ ਪੁੱਛਿਆ। UDP ਅਤੇ TCP 53 ਜਾਂਚੋ, ਕਿਉਂਕਿ ਵੱਡੇ ਜਵਾਬ ਅਤੇ ਕੁਝ ਰਿਜ਼ੋਲਵਰ TCP 'ਤੇ ਵਾਪਸ ਜਾਂਦੇ ਹਨ, ਅਤੇ Pi-hole ਕੰਟੇਨਰ ਵਿੱਚ ਚੱਲਦਾ ਹੋਵੇ ਤਾਂ ਦੋਵੇਂ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰੋ। ਸਿਰਫ਼ UDP ਨੂੰ ਕਵਰ ਕਰਨ ਵਾਲੀ ਮੈਪਿੰਗ ਪੈਕੇਟ ਲੌਸ ਵਰਗੀਆਂ ਰੁਕ-ਰੁਕ ਕੇ ਅਸਫਲਤਾਵਾਂ ਪੈਦਾ ਕਰਦੀ ਹੈ।

ਫਿਰ Pi-hole ਦਾ ਸੁਣਨ ਮੋਡ ਤੈਅ ਕਰਦਾ ਹੈ ਕਿ ਇਹ ਬਿਲਕੁਲ ਜਵਾਬ ਦਿੰਦਾ ਹੈ ਜਾਂ ਨਹੀਂ। ਸਿਰਫ਼-ਸਥਾਨਕ ਮੋਡ ਵਿੱਚ dnsmasq ਸਿੱਧੇ ਜੁੜੇ ਸਬਨੈੱਟ 'ਤੇ ਨਾ ਹੋਣ ਵਾਲੇ ਸਰੋਤਾਂ ਦੀਆਂ ਕੁਇਰੀਆਂ ਅਣਡਿੱਠ ਕਰਦਾ ਹੈ, ਅਤੇ ਦੂਜੇ ਰਾਊਟਰ ਪਿੱਛੇ ਵਾਲਾ ਜਾਂ ਟਨਲ ਰਾਹੀਂ ਆਉਣ ਵਾਲਾ ਕਲਾਇੰਟ ਬਿਲਕੁਲ ਇਸੇ ਤਰ੍ਹਾਂ ਦਿਸਦਾ ਹੈ: ਕਲਾਇੰਟ ਦਾ ਸਮਾਂ ਖ਼ਤਮ ਹੋ ਜਾਂਦਾ ਹੈ ਅਤੇ ਕੁਇਰੀ ਕਦੇ ਲੌਗ ਤੱਕ ਨਹੀਂ ਪਹੁੰਚਦੀ। ਜੋ ਕੁਇਰੀ ਫਿਰ ਵੀ REFUSED ਵਜੋਂ ਦਿਸਦੀ ਹੈ ਉਹ ਪਹੁੰਚ ਸੂਚੀ ਜਾਂ ਫਾਇਰਵਾਲ ਨਿਯਮ ਨੇ ਰੱਦ ਕੀਤੀ ਹੈ। ਸਾਰੇ ਸਰੋਤਾਂ ਨੂੰ ਇਜਾਜ਼ਤ ਦੇਣਾ ਆਮ ਹੱਲ ਹੈ, ਨਾਲ ਹੀ ਇੱਕ ਫਾਇਰਵਾਲ ਨਿਯਮ ਜੋ ਪੋਰਟ 53 ਨੂੰ ਤੁਹਾਡੇ ਆਪਣੇ ਸਬਨੈੱਟ ਤੱਕ ਸੀਮਤ ਕਰਦਾ ਹੈ।

4. ਜਾਂਚੋ ਕਿ ਟਨਲ ਨੇ ਜਵਾਬ ਬਦਲਿਆ ਹੈ ਜਾਂ ਨਿਗਲ ਲਿਆ ਹੈ

ਇਹ ਉਹ ਸਥਿਤੀ ਹੈ ਜਿਸ ਵਿੱਚ ਦੋਵੇਂ ਲੱਛਣ ਲੁਕੇ ਹੁੰਦੇ ਹਨ। ਜਦੋਂ ਰਾਊਟਰ ਖੁਦ VPN ਕਲਾਇੰਟ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਪੁਸ਼ ਕੀਤਾ DNS ਵਿਕਲਪ ਟਨਲ ਉੱਠਣ ਵਾਲੇ ਪਲ ਹੀ LAN ਸੈਟਿੰਗ ਨੂੰ ਪਾਰ ਕਰ ਸਕਦਾ ਹੈ: OpenVPN ਸਰਵਰ dhcp-option DNS ਪੁਸ਼ ਕਰਦੇ ਹਨ, ਅਤੇ WireGuard ਪ੍ਰੋਫਾਈਲ ਆਪਣੀ DNS ਐਂਟਰੀ ਰੱਖਦੇ ਹਨ। ਟਨਲ ਚਾਲੂ ਹੋਣ 'ਤੇ ਰਾਊਟਰ ਦਾ ਪ੍ਰਭਾਵੀ ਰਿਜ਼ੋਲਵਰ ਪੜ੍ਹੋ, ਉਸ ਤੋਂ ਪਹਿਲਾਂ ਨਹੀਂ, ਅਤੇ LAN ਪੇਜ ਜੋ ਦਾਅਵਾ ਕਰਦਾ ਹੈ ਉਸ ਨੂੰ ਅਣਡਿੱਠ ਕਰੋ।

ਦੂਜੀ ਖਰਾਬੀ ਬਦਲੀ ਨਹੀਂ, ਪਹੁੰਚ ਹੈ। ਜੇ ਟਨਲ ਦੇ ਮਨਜ਼ੂਰ ਪ੍ਰੀਫਿਕਸ ਵਿੱਚ ਤੁਹਾਡਾ LAN ਸਬਨੈੱਟ ਸ਼ਾਮਲ ਹੈ, ਤਾਂ ਰਾਊਟਰ ਕੋਲ ਉਹ ਰੂਟ ਹੈ ਜੋ 192.168.1.53 ਲਈ ਕੁਇਰੀਆਂ ਟਨਲ ਵਿੱਚ ਭੇਜਦਾ ਹੈ, ਅਤੇ ਦੂਜੇ ਪਾਸੇ ਵਾਪਸੀ ਦਾ ਕੋਈ ਰੂਟ ਨਹੀਂ: ਟਨਲ ਸਿਹਤਮੰਦ ਹੋਣ 'ਤੇ ਵੀ ਕੁਇਰੀਆਂ ਦਾ ਸਮਾਂ ਖ਼ਤਮ ਹੋ ਜਾਂਦਾ ਹੈ। ਉਲਟਾ ਤਦ ਹੁੰਦਾ ਹੈ ਜਦੋਂ Pi-hole ਅਜਿਹੇ ਸਬਨੈੱਟ ਵਿੱਚ ਹੁੰਦਾ ਹੈ ਜੋ ਟਨਲ ਨਹੀਂ ਲੈ ਕੇ ਜਾਂਦਾ। DNS ਨੂੰ ਦੁਬਾਰਾ ਛੂਹਣ ਤੋਂ ਪਹਿਲਾਂ ਪਤੇ ਦੀ ਟਨਲ ਦੇ ਮਨਜ਼ੂਰ ਪ੍ਰੀਫਿਕਸ ਅਤੇ ਰਾਊਟਰ ਦੀ ਰੂਟ ਟੇਬਲ ਨਾਲ ਤੁਲਨਾ ਕਰੋ।

ਦੋਵੇਂ ਨਹੀਂ, ਇੱਕ ਹੱਲ ਚੁਣੋ। ਜਾਂ ਤਾਂ ਟਨਲ ਨੂੰ DNS ਤੋਂ ਦੂਰ ਰੱਖੋ — OpenVPN 'ਤੇ pull-filter ignore “dhcp-option DNS” ਅਤੇ WireGuard 'ਤੇ AllowedIPs ਵਿੱਚ ਕੋਈ LAN ਪ੍ਰੀਫਿਕਸ ਬਿਨਾਂ —, ਜਾਂ ਪੁਸ਼ ਕੀਤਾ ਰਿਜ਼ੋਲਵਰ ਮੰਨ ਲਓ ਅਤੇ ਉਸ ਰਾਊਟਰ ਪਿੱਛੇ ਵਾਲੇ ਕਲਾਇੰਟਾਂ ਲਈ ਸਥਾਨਕ ਫਿਲਟਰਿੰਗ ਛੱਡ ਦਿਓ। ਤੁਸੀਂ ਜੋ ਵੀ ਚੁਣੋ, ਉਸ ਨੂੰ ਪ੍ਰੋਫਾਈਲ ਦੇ ਕੋਲ ਲਿਖੋ, ਕਿਉਂਕਿ ਅਗਲੀ ਵਾਰ ਇਸ ਨੂੰ ਸੋਧਣ ਵਾਲਾ ਵਿਅਕਤੀ ਨਹੀਂ ਤਾਂ ਹਾਦਸਾਵਸ਼ ਫ਼ੈਸਲਾ ਉਲਟ ਦੇਵੇਗਾ।

5. ਦੁਬਾਰਾ ਜੁੜਨ ਤੋਂ ਬਾਅਦ ਟੈਸਟ ਦੁਹਰਾਓ

ਕਿਸੇ ਕਲਾਇੰਟ ਤੋਂ ਕੁਇਰੀ ਕਰੋ, ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਉਹ ਕਲਾਇੰਟ Pi-hole ਦੇ ਲੌਗ ਵਿੱਚ ਦਿਸਦਾ ਹੈ, ਫਿਰ ਉਹ ਡੋਮੇਨ ਰਿਜ਼ੋਲਵ ਕਰੋ ਜੋ ਬਲੌਕ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਅਤੇ ਜਾਂਚੋ ਕਿ ਤੁਹਾਨੂੰ ਅਸਲ ਜਵਾਬ ਦੀ ਥਾਂ ਬਲੌਕਿੰਗ ਜਵਾਬ ਮਿਲਦਾ ਹੈ। ਟਨਲ ਦੁਬਾਰਾ ਜੋੜੋ ਅਤੇ ਉਹੀ ਦੋ ਕੁਇਰੀਆਂ ਚਲਾਓ, ਕਿਉਂਕਿ ਅਗਲੇ ਜੁੜਨ ਤੱਕ ਹੀ ਟਿਕਣ ਵਾਲੀ ਰਿਜ਼ੋਲਵਰ ਸੈਟਿੰਗ ਗਲਤ ਪਰਤ 'ਤੇ ਲਾਗੂ ਕੀਤੇ ਹੱਲ ਦਾ ਆਮ ਨਤੀਜਾ ਹੈ।

ਟਨਲ 'ਤੇ ਨਿਰਭਰ ਨਾ ਕਰਨ ਵਾਲਾ ਦੂਜਾ ਰਿਜ਼ੋਲਵਰ ਰਾਹ ਛੱਡੋ, ਤਾਂ ਜੋ Pi-hole ਬੰਦ ਪੈਣ 'ਤੇ ਬ੍ਰਾਊਜ਼ਿੰਗ ਬਿਲਕੁਲ ਬੰਦ ਹੋਣ ਦੀ ਥਾਂ ਅਫਿਲਟਰ ਬ੍ਰਾਊਜ਼ਿੰਗ ਤੱਕ ਡਿੱਗੇ। ਟੈਸਟ ਦੋ ਵਾਰ ਪਾਸ ਹੋਣ ਤੱਕ ਪਿਛਲੇ DHCP ਅਤੇ ਰਿਜ਼ੋਲਵਰ ਮੁੱਲ ਰੱਖੋ; ਰਾਤ ਦੇ ਖਾਣੇ ਵੇਲੇ ਘਰ ਦਾ ਇੰਟਰਨੈੱਟ ਤੋੜਨ ਵਾਲੀ ਤਬਦੀਲੀ ਇੱਕ ਮਿੰਟ ਵਿੱਚ ਵਾਪਸ ਲਿਆਉਣ ਵਾਲੀ ਤਬਦੀਲੀ ਨਾਲੋਂ ਕਿਤੇ ਔਖੀ ਡੀਬੱਗ ਹੁੰਦੀ ਹੈ।