OpenVPN ਕਲਾਇੰਟਾਂ ਨੂੰ ਹੋਰ ਹੋਸਟ ’ਤੇ Pi-hole ਰਿਜ਼ਾਲਵਰ ਵੱਲ ਭੇਜੋ

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

ਧੱਕੀ ਗਈ DNS ਚੋਣ ਕੀ ਕਰਦੀ ਹੈ ਅਤੇ ਕੀ ਨਹੀਂ

ਸਰਵਰ ਹੇਠਾਂ ਦਿੱਤੀ ਹਦਾਇਤ ਨਾਲ ਇੱਕ ਰਿਜ਼ਾਲਵਰ ਦਾ ਐਲਾਨ ਕਰਦਾ ਹੈ, ਇਹ ਮੰਨਦੇ ਹੋਏ ਕਿ 192.168.50.53 Pi-hole ਹੋਸਟ ਹੈ। ਕਲਾਇੰਟ ਚੋਣ ਪ੍ਰਾਪਤ ਕਰਦਾ ਹੈ ਅਤੇ, ਆਪਣੇ ਪਲੇਟਫਾਰਮ ਅਤੇ ਰਿਜ਼ਾਲਵਰ ਏਕੀਕਰਨ ਅਨੁਸਾਰ , ਇਸਨੂੰ ਟਨਲ ਇੰਟਰਫੇਸ ’ਤੇ ਲਾਗੂ ਕਰਦਾ ਹੈ ਜਾਂ ਸਥਾਨਕ ਸਟਬ ਦੇ ਹੱਕ ਵਿੱਚ ਅਣਡਿੱਠਾ ਕਰ ਦਿੰਦਾ ਹੈ। ਰੂਟ ਲਾਈਨ DNS ਲਾਈਨ ਜਿੰਨੀ ਹੀ ਮਹੱਤਵਪੂਰਨ ਹੈ, ਕਿਉਂਕਿ ਜਿਸ ਰਿਜ਼ਾਲਵਰ ਤੱਕ ਕਲਾਇੰਟ ਨਹੀਂ ਪਹੁੰਚ ਸਕਦਾ ਉਹ ਕੋਈ ਰਿਜ਼ਾਲਵਰ ਹੀ ਨਹੀਂ। ਇਸ ਵਿੱਚੋਂ ਕੁਝ ਵੀ ਸਰਵਰ ਵੱਲੋਂ ਦਿਸਦਾ ਨਹੀਂ।

server 10.90.0.0 255.255.255.0
push "dhcp-option DNS 192.168.50.53"
push "route 192.168.50.0 255.255.255.0"

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

ਚੋਣ ਸਰਵਰ ਪਾਸੇ ਬਾਰੇ ਵੀ ਕੁਝ ਨਹੀਂ ਕਹਿੰਦੀ। DNS ਟ੍ਰੈਫਿਕ ਨੂੰ ਅਜੇ ਵੀ ਕਲਾਇੰਟ ਤੋਂ ਗੇਟਵੇ ਅਤੇ ਗੇਟਵੇ ਤੋਂ Pi-hole ਤੱਕ ਜਾਣਾ ਪੈਂਦਾ ਹੈ, ਇਸ ਤੋਂ ਪਹਿਲਾਂ ਕਿ ਕੋਈ ਚੋਣ ਮਾਅਨੇ ਰੱਖੇ। ਗੁੰਮ ਰਾਹ ਅਤੇ ਰੱਦ ਕੀਤੀ ਕਵੈਰੀ ਕਲਾਇੰਟ ਵੱਲੋਂ ਇੱਕੋ ਜਿਹੇ ਦਿਸਦੇ ਹਨ, ਇਸ ਲਈ ਪਹਿਲਾਂ ਗੇਟਵੇ ’ਤੇ ਫਾਰਵਰਡਿੰਗ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ।

Pi-hole ਤੋਂ ਪੂਲ ਤੱਕ ਵਾਪਸੀ ਪਥ

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

LAN ਰਾਊਟਰ ਨੂੰ ਪੂਲ ਲਈ ਸਥਿਰ ਰੂਟ ਦਿਓ ਜਿਸ ਵਿੱਚ OpenVPN ਗੇਟਵੇ ਅਗਲਾ ਹੌਪ ਹੋਵੇ, ਜਾਂ Pi-hole ਵੱਲ ਫਾਰਵਰਡ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਗੇਟਵੇ ’ਤੇ ਸਰੋਤ ਦਾ ਅਨੁਵਾਦ ਕਰੋ। ਪਹਿਲਾ ਹਰ ਕਲਾਇੰਟ ਦੇ ਪਤੇ Pi-hole ਦੇ ਕਵੈਰੀ ਲੌਗ ਵਿੱਚ ਦਿਸਦੇ ਰੱਖਦਾ ਹੈ। ਦੂਜਾ ਵਾਪਸੀ ਰੂਟ ਦੀ ਸ਼ਰਤ ਹਟਾਉਂਦਾ ਹੈ ਪਰ ਹਰ ਕਵੈਰੀ ਨੂੰ ਗੇਟਵੇ ਤੋਂ ਆਇਆ ਦਿਖਾਉਂਦਾ ਹੈ। ਕੋਈ ਵੀ ਗਲਤ ਨਹੀਂ; ਉਹ ਵੱਖਰੇ ਸਵਾਲਾਂ ਦੇ ਜਵਾਬ ਦਿੰਦੇ ਹਨ।

ਜੇ ਪ੍ਰਤੀ-ਕਲਾਇੰਟ ਰਿਪੋਰਟਿੰਗ ਜਾਂ ਨੀਤੀ ਮਹੱਤਵਪੂਰਨ ਹੈ, ਤਾਂ ਸਥਿਰ ਰੂਟ ਵਧੀਆ ਸੌਦਾ ਹੈ। ਜੇ LAN ਕਿਸੇ ਹੋਰ ਕੋਲ ਹੈ ਅਤੇ ਕੋਈ ਰੂਟ ਉਪਲਬਧ ਨਹੀਂ, ਤਾਂ ਅਨੁਵਾਦ ਵਿਹਾਰਕ ਚੋਣ ਹੈ, ਕਲਾਇੰਟ ਦੀ ਪਛਾਣ ਦੇ ਨੁਕਸਾਨ ਸਮੇਤ। ਲਿਖੋ ਕਿ ਤੁਸੀਂ ਕਿਹੜਾ ਚੁਣਿਆ, ਕਿਉਂਕਿ ਹਰ ਬਾਅਦ ਵਾਲਾ ਲੌਗ ਸਵਾਲ ਇਸੇ ’ਤੇ ਨਿਰਭਰ ਹੈ।

ਰੂਟ ਕੀਤੇ ਕਲਾਇੰਟਾਂ ਲਈ Pi-hole ਦਾ ਸੁਣਨ ਮੋਡ

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

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

ਪਹਿਲੀ ਕਵੈਰੀ ਦੇ ਕੰਮ ਕਰਨ ਲਈ ਸਾਰੇ ਮੂਲਾਂ ਲਈ ਰਿਕਰਸ਼ਨ ਖੋਲ੍ਹਣਾ ਗਲਤ ਮੁਰੰਮਤ ਹੈ। ਇਹ ਨਿੱਜੀ ਰਿਜ਼ਾਲਵਰ ਨੂੰ ਖੁੱਲ੍ਹਾ ਬਣਾ ਦਿੰਦਾ ਹੈ, ਅਤੇ ਸੁਧਾਰ ਸੀਮਿਤ ਇਜਾਜ਼ਤ ਹੈ, ਵਿਸ਼ਵਵਿਆਪੀ ਨਹੀਂ।

ਜਵਾਬ ਨੂੰ ਕਵੈਰੀ ਲੌਗ ਨਾਲ ਮਿਲਾਓ

ਕਲਾਇੰਟ ਨੂੰ ਪੁੱਛੋ, ਫਿਰ ਸਰਵਰ ਜਾਂਚੋ ਅਤੇ ਦੋਵਾਂ ਦੀ ਤੁਲਨਾ ਕਰੋ। systemd-resolved ਕਲਾਇੰਟ ’ਤੇ ਹੇਠਾਂ ਦਿੱਤੇ ਕਮਾਂਡ ਦੱਸਦੇ ਹਨ ਕਿ ਕਿਸ ਰਿਜ਼ਾਲਵਰ ਨੇ ਜਵਾਬ ਬਣਾਇਆ ਅਤੇ ਪ੍ਰਤੀ ਲਿੰਕ ਕਿਹੜੇ ਸਰਵਰ ਸੰਰਚਿਤ ਹਨ। ਅਜਿਹਾ ਨਾਮ ਵਰਤੋ ਜੋ ਕੇਵਲ Pi-hole ਜਾਣਦਾ ਹੈ, ਕਿਉਂਕਿ Pi-hole ਦੇ ਪਤੇ ’ਤੇ ਸਿੱਧੀ ਕਵੈਰੀ ਪਹੁੰਚ ਸਾਬਤ ਕਰਦੀ ਹੈ, ਸੰਰਚਨਾ ਨਹੀਂ।

resolvectl query intranet.example.lan
resolvectl dns

ਉਮੀਦ ਕੀਤਾ ਜਵਾਬ 192.168.50.53 ਨੂੰ ਸਰਵਰ ਵਜੋਂ ਨਾਮ ਦਿੰਦਾ ਹੈ ਅਤੇ ਅਜਿਹਾ ਪਤਾ ਮੋੜਦਾ ਹੈ ਜੋ ਕੇਵਲ ਉਹੀ ਰਿਜ਼ਾਲਵਰ ਜਾਣਦਾ ਹੋਵੇਗਾ। ਫਿਰ Pi-hole ਦਾ ਆਪਣਾ ਦ੍ਰਿਸ਼ ਵੇਖੋ: pihole -t ਕਵੈਰੀ ਲੌਗ ਨੂੰ ਸਿੱਧਾ ਫਾਲੋ ਕਰਦਾ ਹੈ, ਅਤੇ ਹਰ ਲਾਈਨ ਸਰੋਤ ਪਤਾ ਰੱਖਦੀ ਹੈ। ਜੇ ਸਰੋਤ ਕਲਾਇੰਟ ਦਾ ਟਨਲ ਪਤਾ ਹੈ ਤਾਂ ਪੂਲ ਦਾ ਰੂਟ ਸਹੀ ਹੈ। ਜੇ ਇਹ ਗੇਟਵੇ ਦਾ LAN ਪਤਾ ਹੈ ਤਾਂ ਸਰੋਤ ਅਨੁਵਾਦ ਚੱਲ ਰਿਹਾ ਹੈ ਅਤੇ ਕਲਾਇੰਟ ਦਾ ਆਪਣਾ ਪਤਾ ਕਦੇ ਨਹੀਂ ਦਿਸੇਗਾ।

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

ਗੇਟਵੇ ਦਾ ਫਾਰਵਰਡਿੰਗ ਨਿਯਮ ਜਾਂਚੋ

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

sudo nft list ruleset | grep -A3 'dport 53'
sudo iptables -t nat -L POSTROUTING -n -v | grep 53

ਕਾਊਂਟਰ ਪੜ੍ਹੋ, ਕੇਵਲ ਨਿਯਮ ਨਹੀਂ। ਜੋ ਨਿਯਮ ਕਦੇ ਨਹੀਂ ਮਿਲਦਾ ਉਸਦਾ ਅਰਥ ਹੈ ਕਿ ਪੈਕਟ ਕਿਸੇ ਹੋਰ ਇੰਟਰਫੇਸ ਰਾਹੀਂ ਨਿਕਲਦਾ ਹੈ, ਜਾਂ ਕਲਾਇੰਟ ਨੇ ਇਸਨੂੰ ਕਦੇ ਭੇਜਿਆ ਹੀ ਨਹੀਂ। ਜੋ ਨਿਯਮ ਹਰ ਕਵੈਰੀ ’ਤੇ ਮਿਲਦਾ ਹੈ ਉਸਦਾ ਅਰਥ ਹੈ ਕਿ ਫਾਰਵਰਡਿੰਗ ਕੰਮ ਕਰ ਰਹੀ ਹੈ ਅਤੇ ਸਮੱਸਿਆ ਰਾਹ ਵਿੱਚ ਅੱਗੇ ਹੈ।

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