Pi ਹਾਟਸਪਾਟ Pi-hole ਅਤੇ VPN ਨਾਲ: ਹਰ ਸੇਵਾ ਨੂੰ ਆਪਣਾ ਕੰਮ ਦਿਓ
ਇੱਕੋ Pi ਉੱਤੇ ਤਿੰਨ ਸਹਾਇਕ ਸ਼ੁਰੂ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਤੈਅ ਕਰੋ ਕਿ DHCP, DNS ਅਤੇ ਪੈਕਟ ਫਾਰਵਰਡਿੰਗ ਦਾ ਮਾਲਕ ਕੌਣ ਹੈ। ਦੋਹਰੇ ਮਾਲਕ ਮੁਕਾਬਲੇ ਵਾਲੀਆਂ ਲੀਜ਼ਾਂ ਅਤੇ ਰੈਜ਼ੋਲਵਰ ਲੂਪ ਪੈਦਾ ਕਰਦੇ ਹਨ।
ਇੱਕ ਫੋਨ Pi ਦੇ ਹਾਟਸਪਾਟ ਨਾਲ ਜੁੜਦਾ ਹੈ, ਪਤਾ ਲੈਂਦਾ ਹੈ, ਅਤੇ ਪੰਨਾ ਫਿਰ ਵੀ ਨਹੀਂ ਖੁੱਲ੍ਹਦਾ। Pi ਇੱਕ ਹਾਟਸਪਾਟ ਸਹਾਇਕ, Pi-hole ਅਤੇ VPN ਕਲਾਇੰਟ ਚਲਾ ਰਿਹਾ ਹੈ, ਅਤੇ ਹਰ ਇੱਕ ਸਮਝਦਾ ਹੈ ਕਿ ਉਹ ਰਾਹ ਦਾ ਕੁਝ ਹਿੱਸਾ ਰੱਖਦਾ ਹੈ। ਅਜਿਹੀਆਂ ਬਹੁਤੀਆਂ ਬਿਲਡਾਂ ਕਿਸੇ ਹਿੱਸੇ ਦੇ ਖਰਾਬ ਹੋਣ ਕਰਕੇ ਨਹੀਂ, ਸਗੋਂ ਇਸ ਲਈ ਫੇਲ੍ਹ ਹੁੰਦੀਆਂ ਹਨ ਕਿ ਦੋ ਹਿੱਸੇ ਇੱਕੋ ਕੰਮ ਕਰਦੇ ਹਨ। ਕਿਸੇ ਵੀ ਚੀਜ਼ ਨੂੰ ਟਿਊਨ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਹਰ ਫੰਕਸ਼ਨ ਲਈ ਇੱਕ ਮਾਲਕ ਤੈਅ ਕਰੋ।
ਹਰ ਫੰਕਸ਼ਨ ਲਈ ਇੱਕ ਮਾਲਕ ਤੈਅ ਕਰੋ
ਇੱਥੇ ਚਾਰ ਫੰਕਸ਼ਨ ਮਹੱਤਵਪੂਰਨ ਹਨ, ਅਤੇ ਹਰ ਇੱਕ ਨੂੰ ਬਿਲਕੁਲ ਇੱਕ ਮਾਲਕ ਚਾਹੀਦਾ ਹੈ। ਹੇਠਾਂ ਦਿੱਤੀ ਸਾਰਣੀ ਫੰਕਸ਼ਨ, ਕੰਮ ਕਰਨ ਯੋਗ ਮਾਲਕ ਅਤੇ ਉਹ ਦੱਸਦੀ ਹੈ ਜੋ ਗੜਬੜ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਦੋ ਸੇਵਾਵਾਂ ਇਸ 'ਤੇ ਦਾਅਵਾ ਕਰਦੀਆਂ ਹਨ।
| Function | Workable owner | Duplicate-owner symptom |
|---|---|---|
| Client addresses | One DHCP server, such as the hotspot helper | Competing offers and changing leases |
| DNS reception | Pi-hole on port 53 | Bind failure or queries answered by the wrong process |
| Forwarding and NAT | One firewall manager | Double translation and broken return paths |
| VPN routing | One client configuration | Route flapping and traffic escaping outside the tunnel |
ਓਵਰਲੈਪ ਆਮ ਤੌਰ 'ਤੇ ਇੱਕ ਸਮੇਂ ਇੱਕ ਪੈਕਟ ਆਉਂਦਾ ਹੈ। ਹਾਟਸਪਾਟ ਸਹਾਇਕ ਆਪਣੀ dnsmasq ਕਾਪੀ ਸਥਾਪਤ ਕਰਦਾ ਹੈ, Pi-hole ਨੂੰ ਪੋਰਟ 53 ਚਾਹੀਦਾ ਹੈ, ਅਤੇ VPN ਕਲਾਇੰਟ ਰੂਟ ਜੋੜਦਾ ਹੈ। ਹਰ ਕਦਮ ਇਕੱਲਾ ਵਾਜਬ ਲੱਗਦਾ ਹੈ, ਅਤੇ ਮਿਲ ਕੇ ਅਜਿਹੀ ਮਸ਼ੀਨ ਬਣਾਉਂਦੇ ਹਨ ਜਿੱਥੇ ਦੂਜੀ ਸ਼ੁਰੂ ਹੋਣ ਵਾਲੀ ਸੇਵਾ ਪਹਿਲੀ ਦਾ ਵਿਵਹਾਰ ਚੁੱਪਚਾਪ ਬਦਲ ਦਿੰਦੀ ਹੈ।
ਕੁਝ ਹੋਰ ਸ਼ੁਰੂ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਮਾਲਕ ਲਿਖ ਲਓ। ਬਿਲਡ ਨੋਟਸ ਵਿੱਚ ਛੋਟੀ ਸਾਰਣੀ ਬਾਅਦ ਦੀ ਇੰਸਟਾਲ ਨੂੰ ਪਹਿਲਾਂ ਹੀ ਮਾਲਕ ਵਾਲੇ ਫੰਕਸ਼ਨ 'ਤੇ ਕਬਜ਼ਾ ਕਰਨ ਤੋਂ ਰੋਕਦੀ ਹੈ।
ਇੱਕ ਰੇਂਜ ਚੁਣੋ ਅਤੇ ਇਸਨੂੰ ਟਨਲ ਤੋਂ ਦੂਰ ਰੱਖੋ
ਹਾਟਸਪਾਟ ਦੀ ਰੇਂਜ, ਇਸ ਵਿੱਚ Pi ਦਾ ਪਤਾ, DHCP ਪੂਲ ਅਤੇ ਉਹ ਰੈਜ਼ੋਲਵਰ ਚੁਣੋ ਜੋ ਕਲਾਇੰਟ ਨੂੰ ਮਿਲਦਾ ਹੈ। ਉਹ ਰੇਂਜ ਉੱਪਰਲੇ LAN ਅਤੇ VPN ਟਨਲ ਦੀ ਰੇਂਜ ਤੋਂ ਵੱਖ ਰੱਖੋ, ਕਿਉਂਕਿ ਓਵਰਲੈਪ ਹੁੰਦੀਆਂ ਸਬਨੈੱਟਾਂ ਰਾਊਟਿੰਗ ਦੀ ਸਮੱਸਿਆ ਨੂੰ ਪਤਾ ਅਨੁਵਾਦ ਦੇ ਪ੍ਰੋਜੈਕਟ ਵਿੱਚ ਬਦਲ ਦਿੰਦੀਆਂ ਹਨ। ਟਨਲ ਨਾਲ ਓਵਰਲੈਪ ਹੁੰਦੀ ਰੇਂਜ Pi ਨੂੰ ਦੋ ਸਮਾਨ ਪ੍ਰੀਫਿਕਸਾਂ ਵਿਚਕਾਰ ਅਚਾਨਕ ਰਾਊਟਰ ਬਣਾ ਦਿੰਦੀ ਹੈ। ਰੇਂਜ ਅਤੇ ਪੂਲ ਨੂੰ ਡਿਫਾਲਟ 'ਤੇ ਛੱਡਣ ਦੀ ਬਜਾਏ ਹਾਟਸਪਾਟ ਕਨਫਿਗਰੇਸ਼ਨ ਵਿੱਚ ਲਿਖੋ।
ਜੇ ਹਾਟਸਪਾਟ NetworkManager ਦੇ ਸ਼ੇਅਰਡ ਮੋਡ ਕੋਲ ਹੈ, ਤਾਂ DHCP ਸਰਵਰ ਜੋੜਨ ਤੋਂ ਪਹਿਲਾਂ ਪ੍ਰਭਾਵੀ ਕਨੈਕਸ਼ਨ ਦੀ ਜਾਂਚ ਕਰੋ। ਸ਼ੇਅਰਡ ਮੋਡ ਆਪਣੇ ਸਹਾਇਕ ਸ਼ੁਰੂ ਕਰਦਾ ਹੈ ਅਤੇ ਫਾਰਵਰਡਿੰਗ ਚਾਲੂ ਕਰਦਾ ਹੈ, ਇਸ ਲਈ ਉਹ ਉਸ ਇੰਟਰਫੇਸ ਦੇ ਪਤਾ ਪਲਾਨ ਦਾ ਪਹਿਲਾਂ ਹੀ ਮਾਲਕ ਹੈ। ਸਿਰਫ਼ ਉਪਲਬਧ ਹੋਣ ਕਰਕੇ ਦੂਜਾ ਸਰਵਰ ਜੋੜਨਾ ਰਿਡੰਡੈਂਸੀ ਦੀ ਬਜਾਏ ਮੁਕਾਬਲੇ ਵਾਲੇ ਪੇਸ਼ਕਸ਼ ਬਣਾਉਂਦਾ ਹੈ।
IPv6 ਬਾਰੇ ਸੋਚ-ਸਮਝ ਕੇ ਫੈਸਲਾ ਕਰੋ। ਰਾਊਟਰ ਐਲਾਨ ਅਤੇ DHCPv6 ਕਈ ਸੈਟਅਪਾਂ ਵਿੱਚ DHCPv4 ਤੋਂ ਵੱਖਰੇ ਸਹਾਇਕ ਤੋਂ ਆਉਂਦੇ ਹਨ, ਅਤੇ IPv6 ਨੂੰ ਚਾਲੂ ਰੱਖਣਾ ਜਦੋਂ VPN ਨੀਤੀ ਸਿਰਫ਼ IPv4 ਨੂੰ ਕਵਰ ਕਰਦੀ ਹੈ, ਕਲਾਇੰਟ ਨੂੰ ਟਨਲ ਤੋਂ ਬਚਣ ਵਾਲਾ ਰਾਹ ਦੇ ਦਿੰਦਾ ਹੈ। ਜਾਂ ਤਾਂ IPv6 ਪਾਸੇ ਦੀ ਯੋਜਨਾ ਬਣਾਓ ਜਾਂ ਇਸਨੂੰ ਹਾਟਸਪਾਟ ਇੰਟਰਫੇਸ 'ਤੇ ਲਿਖਤੀ ਕਾਰਨ ਨਾਲ ਬੰਦ ਕਰੋ।
ਪੋਰਟ 53 'ਤੇ ਅਸਲ ਵਿੱਚ ਕੌਣ ਜਵਾਬ ਦਿੰਦਾ ਹੈ
ਕਨਫਿਗਰੇਸ਼ਨ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ ਪੋਰਟ 53 'ਤੇ ਸੁਣਨ ਵਾਲੀ ਹਰ ਪ੍ਰਕਿਰਿਆ ਦੀ ਸੂਚੀ ਬਣਾਓ। ਸਥਾਨਕ ਰੈਜ਼ੋਲਵਰ stub, Pi-hole ਅਤੇ ਸ਼ੇਅਰਿੰਗ ਸਹਾਇਕ ਚਲਾਉਣ ਵਾਲੇ Pi 'ਤੇ, ਸੁਣਨ ਵਾਲਿਆਂ ਦੀ ਸੂਚੀ ਹੀ ਇਸ ਦਾ ਇੱਕਮਾਤਰ ਭਰੋਸੇਯੋਗ ਨਕਸ਼ਾ ਹੈ ਕਿ ਕਿਊਰੀਆਂ ਦਾ ਜਵਾਬ ਕੌਣ ਦਿੰਦਾ ਹੈ:
sudo ss -lunpt '( sport = :53 )'
ip -4 addr show
ip routePi-hole ਦੀ ਇੰਟਰਫੇਸ ਗਾਈਡ ਦੱਸਦੀ ਹੈ ਕਿ ਇੱਕ ਇੰਟਰਫੇਸ ਤੱਕ ਸੀਮਿਤ ਪ੍ਰਾਪਤੀ ਮੋਡ ਫਿਰ ਵੀ wildcard ਸਾਕਟ ਵਰਤ ਸਕਦਾ ਹੈ ਅਤੇ ਹੋਰ ਕਿਤੇ ਆਉਣ ਵਾਲੇ ਪੈਕਟ ਸੁੱਟ ਸਕਦਾ ਹੈ। ਇਹ ਸਿਰਫ਼ ਚੁਣੇ ਇੰਟਰਫੇਸ ਬੰਨ੍ਹਣ ਵਰਗਾ ਨਹੀਂ, ਜੋ ਉਦੋਂ ਲੋੜੀਂਦਾ ਪ੍ਰਬੰਧ ਹੈ ਜਦੋਂ ਕਿਸੇ ਹੋਰ DNS ਸੇਵਾ ਨੂੰ ਮਸ਼ੀਨ ਸਾਂਝੀ ਕਰਨੀ ਹੋਵੇ।
ਦੋ ਪ੍ਰਕਿਰਿਆਵਾਂ ਆਮ ਤੌਰ 'ਤੇ ਇੱਕੋ ਪਤਾ ਅਤੇ ਪੋਰਟ ਨਹੀਂ ਬੰਨ੍ਹ ਸਕਦੀਆਂ, ਹਾਲਾਂਕਿ SO_REUSEPORT ਸਾਂਝੇ ਬਾਈਂਡ ਨੂੰ ਸਫਲ ਬਣਾ ਸਕਦਾ ਹੈ; ਫਿਰ ਵੀ wildcard ਸੁਣਨ ਵਾਲਾ ਤੰਗ ਸੇਵਾ ਲਈ ਆਏ ਪੈਕਟ ਲੈ ਸਕਦਾ ਹੈ। ਲੋੜੀਂਦੀ ਭੂਮਿਕਾ ਲਈ ਦਸਤਾਵੇਜ਼ੀ ਮੋਡ ਚੁਣੋ ਅਤੇ ਸੇਵਾਵਾਂ ਨੂੰ ਲੋੜੀਂਦੇ ਕ੍ਰਮ ਵਿੱਚ ਮੁੜ ਸ਼ੁਰੂ ਕਰੋ।
Pi-hole ਦਾ ਪ੍ਰਬੰਧਨ ਪੰਨਾ ਹਾਟਸਪਾਟ ਨੈੱਟਵਰਕ ਤੋਂ ਬਾਹਰ ਰੱਖੋ। ਕਲਾਇੰਟ ਨੂੰ ਰੈਜ਼ੋਲਵਰ ਚਾਹੀਦਾ ਹੈ, ਉਹ ਵੈੱਬ ਇੰਟਰਫੇਸ ਜਾਂ API ਨਹੀਂ ਜੋ ਰੈਜ਼ੋਲਵਰ ਦੀ ਕਨਫਿਗਰੇਸ਼ਨ ਬਦਲ ਸਕੇ।
DNS ਦੀਆਂ ਦੋ ਲੱਤਾਂ, ਹਰ ਇੱਕ ਲਈ ਇੱਕ ਨੀਤੀ
ਕਲਾਇੰਟ ਦੀ ਕਿਊਰੀ ਫੋਨ ਤੋਂ Pi ਤੱਕ ਜਾਂਦੀ ਹੈ, ਅਤੇ ਇੱਕ ਵੱਖਰੀ ਕਿਊਰੀ Pi ਤੋਂ ਉਸ ਦੇ ਉੱਪਰਲੇ ਰੈਜ਼ੋਲਵਰ ਤੱਕ ਜਾਂਦੀ ਹੈ। ਫਾਰਵਰਡ ਕੀਤੇ ਹਾਟਸਪਾਟ ਟ੍ਰੈਫਿਕ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਰਾਊਟਿੰਗ ਨਿਯਮ ਦੂਜੀ ਲੱਤ 'ਤੇ ਆਪਣੇ ਆਪ ਲਾਗੂ ਨਹੀਂ ਹੁੰਦਾ, ਕਿਉਂਕਿ Pi ਉਹ ਟ੍ਰੈਫਿਕ ਸਥਾਨਕ ਤੌਰ 'ਤੇ ਬਣਾਉਂਦਾ ਹੈ। ਜੇ VPN ਨੂੰ DNS ਢੋਣਾ ਹੈ, ਤਾਂ ਸਥਾਨਕ ਰਾਹ ਨੂੰ ਆਪਣੀ ਨੀਤੀ ਚਾਹੀਦੀ ਹੈ।
ਲੂਪ ਤੋਂ ਸਾਵਧਾਨ ਰਹੋ। Pi-hole ਦੇ ਉੱਪਰਲੇ ਰੈਜ਼ੋਲਵਰ ਨੂੰ ਉਸ ਪਤੇ ਵੱਲ ਮੋੜਨਾ ਜੋ Pi ਖੁਦ ਸੇਵਾ ਕਰਦਾ ਹੈ, ਸਿੱਧਾ ਜਾਂ ਪੋਰਟ-ਫਾਰਵਰਡ ਰਾਹੀਂ, ਅਜਿਹੀਆਂ ਕਿਊਰੀਆਂ ਬਣਾਉਂਦਾ ਹੈ ਜੋ ਸਮਾਂ ਖਤਮ ਹੋਣ ਤੱਕ ਘੁੰਮਦੀਆਂ ਹਨ। ਇਸਨੂੰ ਅਸਲੀ ਉੱਪਰਲਾ ਰੈਜ਼ੋਲਵਰ ਦਿਓ ਜਾਂ ਉਨ੍ਹਾਂ ਡੋਮੇਨਾਂ ਲਈ ਸ਼ਰਤੀ ਫਾਰਵਰਡਰ ਦਿਓ ਜਿਨ੍ਹਾਂ ਦਾ ਇਹ ਜਵਾਬ ਨਹੀਂ ਦੇ ਸਕਦਾ।
ਤੈਅ ਕਰੋ ਕਿ ਟਨਲ ਡਿੱਗਣ 'ਤੇ ਕੀ ਹੁੰਦਾ ਹੈ। ਸਥਾਨਕ ਰੈਜ਼ੋਲਵਰ 'ਤੇ ਵਾਪਸ ਆਉਣਾ ਬ੍ਰਾਊਜ਼ਿੰਗ ਨੂੰ ਜੀਵਤ ਰੱਖਦਾ ਹੈ ਪਰ ਨਾਮ VPN ਤੋਂ ਬਾਹਰ ਲੈ ਜਾ ਸਕਦਾ ਹੈ; ਬਲਾਕ ਕਰਨਾ ਨੀਤੀ ਨੂੰ ਬਰਕਰਾਰ ਰੱਖਦਾ ਹੈ ਅਤੇ ਖਰਾਬੀ ਨੂੰ ਦਿਸਣ ਵਾਲੀ ਗਲਤੀ ਬਣਾ ਦਿੰਦਾ ਹੈ। ਦੋਵੇਂ ਵਿਕਲਪ ਵਾਜਬ ਹਨ, ਪਰ ਉਨ੍ਹਾਂ ਨੂੰ ਚੁਣਨਾ ਪਵੇਗਾ, ਡਿਫਾਲਟ ਤੋਂ ਵਿਰਾਸਤ ਵਿੱਚ ਨਹੀਂ ਲੈਣਾ।
ਰਾਹ ਅਤੇ ਖਰਾਬੀ ਵੇਲੇ ਦਾ ਵਿਵਹਾਰ ਸਾਬਤ ਕਰੋ
ਪਰਤਾਂ ਵਿੱਚ ਜਾਂਚੋ: ਕਲਾਇੰਟ ਨੂੰ ਪਤਾ ਮਿਲਦਾ ਹੈ, ਕਲਾਇੰਟ Pi ਰਾਹੀਂ ਨਾਮ ਹੱਲ ਕਰਦਾ ਹੈ, Pi ਲੋੜੀਂਦੇ ਉੱਪਰਲੇ ਰੈਜ਼ੋਲਵਰ ਰਾਹੀਂ ਹੱਲ ਕਰਦਾ ਹੈ, ਅਤੇ ਐਪਲੀਕੇਸ਼ਨ ਬੇਨਤੀ ਪੂਰੀ ਕਰਦੀ ਹੈ। ਸਫਲ ਪਿੰਗ DNS ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਦੱਸਦਾ, ਅਤੇ ਸਫਲ ਖੋਜ ਫਾਰਵਰਡਿੰਗ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਦੱਸਦੀ।
dig @192.168.70.1 example.com
curl -sS -o /dev/null -w '%{http_code}\n' https://example.com/
ip -4 route get 1.1.1.1ਫਿਰ ਟਨਲ ਰੋਕੋ ਅਤੇ ਦੁਹਰਾਓ। ਲੋੜੀਂਦਾ ਵਿਵਹਾਰ ਕੁਝ ਸਕਿੰਟਾਂ ਵਿੱਚ ਦਿਸਣਾ ਚਾਹੀਦਾ ਹੈ, Pi-hole ਜਾਂ ਹਾਟਸਪਾਟ ਸੇਵਾ ਨੂੰ ਹੱਥੀਂ ਮੁੜ ਸ਼ੁਰੂ ਕਰਨ ਤੋਂ ਬਾਅਦ ਨਹੀਂ। ਖਰਾਬੀ ਦੌਰਾਨ ਕਲਾਇੰਟ ਦੀ ਰੈਜ਼ੋਲਵਰ ਸੈਟਿੰਗ ਜਾਂਚੋ, ਕਿਉਂਕਿ ਦੂਜਾ ਜਨਤਕ ਰੈਜ਼ੋਲਵਰ ਜਵਾਬ ਦਿੰਦਾ ਰਹੇਗਾ ਭਾਵੇਂ ਨੀਤੀ ਫੇਲ੍ਹ ਹੋਣ ਦੀ ਉਮੀਦ ਕਰ ਰਹੀ ਹੋਵੇ।
ਫਾਰਵਰਡਿੰਗ ਅਤੇ NAT ਲਈ ਇੱਕ ਮਾਲਕ ਰੱਖੋ ਅਤੇ ਇਸਨੂੰ ਕਲਾਇੰਟ ਤੋਂ ਜਾਂਚੋ, Pi ਖੁਦ ਤੋਂ ਨਹੀਂ। Pi ਤੋਂ ਸਫਲਤਾਪੂਰਵਕ ਨਿਕਲਣ ਵਾਲੀ ਬੇਨਤੀ ਵਾਪਸੀ ਦੇ ਰਾਹ 'ਤੇ ਫਿਰ ਵੀ ਡਿੱਗ ਸਕਦੀ ਹੈ, ਅਤੇ ਕਲਾਇੰਟ ਹੀ ਇੱਕੋ-ਇੱਕ ਥਾਂ ਹੈ ਜਿੱਥੇ ਪੂਰਾ ਰਾਹ ਦਿਸਦਾ ਹੈ।