WireGuard ਸੁਰੱਖਿਅਤ ਕਰਨ ਲਈ IPv6 ਬਲਾਕ ਕਰਨਾ ਹੋਸਟ ਤੋੜ ਦਿੰਦਾ ਹੈ

ਟੀਚਾ ਵਾਜਬ ਹੈ: ਇਸ ਮਸ਼ੀਨ ਦੀਆਂ ਸੇਵਾਵਾਂ ਤੱਕ ਸਿਰਫ਼ ਟਨਲ ਵਰਤੋਂਕਾਰ ਹੀ ਪਹੁੰਚਣੇ ਚਾਹੀਦੇ ਹਨ। ਲੋਕ ਜੋ ਅਮਲ ਚੁਣਦੇ ਹਨ ਉਹ IPv6 ਇਨਪੁਟ ਚੇਨ ਹੈ ਜੋ WireGuard ਤੋਂ ਬਿਨਾਂ ਸਭ ਕੁਝ ਡ੍ਰੌਪ ਕਰਦੀ ਹੈ, ਅਤੇ ਇਸ ਨਾਲ ਉਹ ਟ੍ਰੈਫਿਕ ਵੀ ਡ੍ਰੌਪ ਹੋ ਜਾਂਦਾ ਹੈ ਜੋ ਹੋਸਟ ਨੂੰ ਆਪਣੀ ਹੀ ਲਿੰਕ ਨਾਲ ਜੋੜੀ ਰੱਖਦਾ ਹੈ। ਗੁਆਂਢੀ ਖੋਜ ਅਤੇ ਪਾਥ-ਰਖਰੱਖਿਆ ਸੁਨੇਹੇ ਸੇਵਾ-ਪਹੁੰਚ ਨਹੀਂ ਹਨ, ਅਤੇ ਇਹਨਾਂ ਨੂੰ ਹਟਾਉਣ ਨਾਲ ਅਜਿਹੀ ਮਸ਼ੀਨ ਬਣਦੀ ਹੈ ਜੋ ਤੁਹਾਡੀ ਨੀਤੀ ਨਾਲ ਸੰਬੰਧ ਨਾ ਰੱਖਣ ਵਾਲੇ ਕਾਰਨਾਂ ਕਰਕੇ ਪਹੁੰਚ ਤੋਂ ਬਾਹਰ ਹੈ। ਟਨਲ ਉੱਪਰ ਆਉਂਦੀ ਹੈ, ਸੇਵਾਵਾਂ ਠੀਕ ਤਰ੍ਹਾਂ ਸੀਮਿਤ ਹਨ, ਅਤੇ ਲਿੰਕ ਉੱਤੇ ਹੋਰ ਕੁਝ ਨਹੀਂ ਚੱਲਦਾ।

ਤਿੰਨ ਜ਼ਿੰਮੇਵਾਰੀਆਂ, ਇੱਕ ਨਿਯਮ-ਸਮੂਹ

ਪਹਿਲੀ ਜ਼ਿੰਮੇਵਾਰੀ ਬਾਹਰੀ ਨੈੱਟਵਰਕ ਦਾ ਸੰਚਾਲਨ ਹੈ: ਹੋਸਟ ਨੂੰ ਆਪਣੀ ਲਿੰਕ ਉੱਤੇ ਰਹਿਣਾ ਚਾਹੀਦਾ ਹੈ, ਗੁਆਂਢੀਆਂ ਨੂੰ ਹੱਲ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ ਅਤੇ ਉਸ ਲਿੰਕ ਦੀਆਂ ਪਾਥ-ਹੱਦਾਂ ਜਾਣਨੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ। ਦੂਜੀ ਇਨਕ੍ਰਿਪਟਿਡ ਸਰੋਤਾ ਹੈ, ਜੋ ਤੁਹਾਡੇ ਚੁਣੇ ਪਤੇ ਅਤੇ ਪੋਰਟ ਉੱਤੇ UDP ਸਵੀਕਾਰ ਕਰਦੀ ਹੈ। ਤੀਜੀ ਉਹਨਾਂ ਡੀਕ੍ਰਿਪਟ ਕੀਤੀਆਂ ਸੇਵਾਵਾਂ ਦਾ ਸਮੂਹ ਹੈ ਜਿੱਥੇ ਤੁਸੀਂ ਟਨਲ ਵਰਤੋਂਕਾਰਾਂ ਨੂੰ ਪਹੁੰਚਾਉਣਾ ਚਾਹੁੰਦੇ ਹੋ।

ਇਹ ਤਿੰਨ ਵੱਖਰੀਆਂ ਨੀਤੀਆਂ ਹਨ, ਅਤੇ ਸਿਰਫ਼ ਦੂਜੀ ਅਤੇ ਤੀਜੀ VPN ਨਾਲ ਸੰਬੰਧਿਤ ਹਨ। ਜੋ ਨਿਯਮ-ਸਮੂਹ ਇਹਨਾਂ ਨੂੰ ਇੱਕ ਮੰਨਦਾ ਹੈ ਉਹ ਅਜਿਹੀ ਅਸਫਲਤਾ ਵਿਰਾਸਤ ਵਿੱਚ ਪਾਉਂਦਾ ਹੈ ਜਿੱਥੇ ਐਪਲੀਕੇਸ਼ਨ ਹੱਦ ਕੱਸਣ ਨਾਲ ਹੋਸਟ ਦਾ ਜੁੜਾਅ ਚੁੱਪਚਾਪ ਟੁੱਟ ਜਾਂਦਾ ਹੈ।

ਇਹਨਾਂ ਨੂੰ ਵੱਖਰੀਆਂ ਚੇਨਾਂ ਵਿੱਚ ਜਾਂ ਘੱਟੋ-ਘੱਟ ਵੱਖਰੀਆਂ ਟਿੱਪਣੀਆਂ ਵਿੱਚ ਰੱਖੋ, ਤਾਂ ਜੋ ਅਗਲਾ ਵਿਅਕਤੀ ਦੇਖ ਸਕੇ ਕਿ ਕਿਹੜੀ ਲਾਈਨ ਕਿਸ ਕਾਰਨ ਹੈ।

ICMPv6 ਹੋਸਟ ਲਈ ਕੀ ਕਰਦਾ ਹੈ

IPv6 ਗੂੰਜ ਨਾਲੋਂ ਕਿਤੇ ਵੱਧ ਚੀਜ਼ਾਂ ਲਈ ICMPv6 ਉੱਤੇ ਨਿਰਭਰ ਹੈ। ਗੁਆਂਢੀ ਬੇਨਤੀ ਅਤੇ ਘੋਸ਼ਣਾ ARP ਦੀ ਥਾਂ ਲੈਂਦੀਆਂ ਹਨ ਅਤੇ ਸਥਾਨਕ ਡਿਲੀਵਰੀ ਲਈ ਜ਼ਰੂਰੀ ਹਨ। Packet Too Big ਪਾਥ ਦੀ MTU ਜਾਣਕਾਰੀ ਲਿਜਾਂਦਾ ਹੈ, ਅਤੇ ਇਸਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰਨ ਨਾਲ ਵੱਡੇ ਪੈਕਟਾਂ ਉੱਤੇ ਅਟਕਣ ਵਾਲੇ ਸਥਾਨਾਂਤਰਣ ਬਣਦੇ ਹਨ। ਜਦੋਂ ਲਿੰਕ ਸਵੈਚਾਲਿਤ ਸੰਰਚਨਾ ਵਰਤਦੀ ਹੈ ਤਾਂ ਰਾਊਟਰ ਘੋਸ਼ਣਾਵਾਂ ਡਿਫ਼ਾਲਟ ਰੂਟ ਅਤੇ ਪ੍ਰੀਫਿਕਸ ਜਾਣਕਾਰੀ ਲਿਜਾਂਦੀਆਂ ਹਨ।

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

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

ਇਹ ਸਭ ਨੂੰ ਸਰਵਵਿਆਪੀ ICMPv6 ਮਨਜ਼ੂਰੀ ਨਾਲ ਬਦਲਣ ਨਾਲ ਉਪਲਬਧਤਾ ਦੀ ਸਮੱਸਿਆ ਹੱਲ ਹੁੰਦੀ ਹੈ ਅਤੇ ਫਿਲਟਰਿੰਗ ਛੱਡ ਦਿੱਤੀ ਜਾਂਦੀ ਹੈ। ਇਸਨੂੰ ਸਰਵਵਿਆਪੀ ਡ੍ਰੌਪ ਨਾਲ ਬਦਲਣ ਨਾਲ ਫਿਲਟਰਿੰਗ ਦੀ ਸਮੱਸਿਆ ਹੱਲ ਹੁੰਦੀ ਹੈ ਅਤੇ ਹੋਸਟ ਛੱਡ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ।

ਪਹਿਲਾਂ ਟਨਲ ਨੂੰ ਮਨਜ਼ੂਰੀ ਦਿਓ, ਫਿਰ ਸੇਵਾ ਨੂੰ

ਇੱਛਤ ਬਾਹਰੀ ਪਤੇ ਅਤੇ UDP ਪੋਰਟ ਉੱਤੇ WireGuard ਟ੍ਰਾਂਸਪੋਰਟ ਸਵੀਕਾਰ ਕਰੋ, ਅਤੇ ਵਾਪਸ ਆਉਣ ਵਾਲਾ ਟ੍ਰੈਫਿਕ ਕਨੈਕਸ਼ਨ ਟ੍ਰੈਕਿੰਗ ਰਾਹੀਂ ਸਵੀਕਾਰ ਕਰੋ। ਫਿਰ ਟਨਲ ਇੰਟਰਫ਼ੇਸ ਰਾਹੀਂ ਐਪਲੀਕੇਸ਼ਨ ਸੇਵਾਵਾਂ ਨੂੰ ਮਨਜ਼ੂਰੀ ਦਿਓ, ਉਹਨਾਂ ਸਰੋਤਾਂ ਤੋਂ ਜਿਨ੍ਹਾਂ ਨੂੰ ਤੁਸੀਂ ਸੱਚਮੁੱਚ ਅਧਿਕਾਰ ਦਿੰਦੇ ਹੋ।

ਬਾਹਰੀ UDP ਪੋਰਟ ਦੀ ਮਨਜ਼ੂਰੀ ਇਸਦੇ ਅੰਦਰਲੀਆਂ ਡੀਕ੍ਰਿਪਟ ਕੀਤੀਆਂ ਬੇਨਤੀਆਂ ਨੂੰ ਅਧਿਕਾਰ ਨਹੀਂ ਦਿੰਦੀ। ਇਹੀ ਫ਼ਰਕ ਸੇਵਾ-ਨਿਯਮਾਂ ਵਿੱਚ ਟਨਲ ਇੰਟਰਫ਼ੇਸ ਦਿਖਣ ਦਾ ਪੂਰਾ ਕਾਰਨ ਹੈ।

ਫ਼ਾਈਲ ਜਿਵੇਂ ਦੱਸਦੀ ਹੈ ਉਵੇਂ ਨਹੀਂ, ਨਿਯਮ-ਸਮੂਹ ਜਿਵੇਂ ਹੈ ਉਵੇਂ ਪੜ੍ਹੋ:

sudo nft list ruleset
ip -6 addr show
ip -6 route show default

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

ਲਿੰਕ ਦੀ ਜਾਂਚ ਕਰੋ, ਸਿਰਫ਼ ਟਨਲ ਦੀ ਨਹੀਂ

ਬਦਲਾਅ ਤੋਂ ਬਾਅਦ ਚੱਲਦੀ ਟਨਲ ਦਿਸਣ ਨਾਲੋਂ ਘੱਟ ਸਾਬਤ ਕਰਦੀ ਹੈ, ਕਿਉਂਕਿ ਮੌਜੂਦਾ ਗੁਆਂਢੀ ਐਂਟਰੀ ਅਤੇ ਸਥਾਪਿਤ ਕਨੈਕਸ਼ਨ ਉਹ ਨਿਯੰਤਰਣ ਸੁਨੇਹਾ ਲੁਕਾ ਸਕਦੇ ਹਨ ਜਿਸਨੂੰ ਨੀਤੀ ਹੁਣ ਡ੍ਰੌਪ ਕਰ ਰਹੀ ਹੈ।

ਜੁੜਾਅ ਸਿੱਧਾ ਜਾਂਚੋ, ਫਿਰ ਜਾਂਚੋ ਕਿ ਬਾਹਰ ਰੱਖਿਆ ਪਾਥ ਅਜੇ ਵੀ ਅਸਫਲ ਹੁੰਦਾ ਹੈ:

ip -6 neigh show
ping -6 -c 3 2001:db8:1::1
sudo nft -c -f /etc/nftables.conf

ਰੀਬੂਟ ਤੋਂ ਬਾਅਦ ਵੀ ਗੁਆਂਢੀ ਸਾਰਣੀ ਪੂਰੀ ਰਹਿਣਾ ਇਸ ਗੱਲ ਦਾ ਸੰਕੇਤ ਹੈ ਕਿ ਖੋਜ ਅਜੇ ਵੀ ਕੰਮ ਕਰਦੀ ਹੈ। ਖਾਲੀ ਹੋ ਕੇ ਫਿਰ ਕਦੇ ਨ ਭਰਨ ਵਾਲੀ ਸਾਰਣੀ ਇਸ ਗੱਲ ਦਾ ਸੰਕੇਤ ਹੈ ਕਿ ਤੁਸੀਂ ਇਸਨੂੰ ਫਿਲਟਰ ਕਰ ਦਿੱਤਾ। ਤੀਜਾ ਹੁਕਮ ਨਿਯਮ-ਸਮੂਹ ਨੂੰ ਲਾਗੂ ਕੀਤੇ ਬਿਨਾਂ ਇਸਦਾ ਵਾਕ-ਢਾਂਚਾ ਜਾਂਚਦਾ ਹੈ, ਜੋ ਸੈਸ਼ਨ ਹੁੰਦਿਆਂ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ।

ਜਿਸ ਹੋਸਟ ਵਿੱਚੋਂ ਤੁਸੀਂ ਆਪਣੇ ਆਪ ਨੂੰ ਬਾਹਰ ਤਾਲਾ ਲਾ ਬੈਠੇ, ਉਸਨੂੰ ਬਹਾਲ ਕਰੋ

ਆਪਣੇ ਪ੍ਰਬੰਧਕੀ ਸੈਸ਼ਨ ਨੂੰ ਢੋਣ ਵਾਲੇ ਫਾਇਰਵਾਲ ਨਿਯਮ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ ਦੂਜਾ ਚੈਨਲ ਰੱਖੋ: ਕੰਸੋਲ, ਸੀਰੀਅਲ ਕਨੈਕਸ਼ਨ, ਜਾਂ ਨਿਯਤ ਰੋਲਬੈਕ ਜੋ ਰੱਦ ਨ ਕਰੋ ਤਾਂ ਨਵੇਂ ਨਿਯਮ ਹਟਾ ਦਿੰਦਾ ਹੈ।

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

ਅੰਤਿਮ ਨੀਤੀ ਸਰਵਵਿਆਪੀ ਨਹੀਂ ਹੈ। ਪਤਾ, ਰੂਟਿੰਗ ਅਤੇ ਫਾਇਰਵਾਲ ਅਮਲ ਤੈਨਾਤੀ ਦੇ ਇਨਪੁਟ ਹਨ, ਪਰ ਹੱਦ ਹਰ ਥਾਂ ਇੱਕੋ ਹੈ: ਅਧਿਕ੍ਰਿਤ ਟਨਲ ਢੋਣ ਵਾਲਾ ਨਿਯੰਤਰਣ ਟ੍ਰੈਫਿਕ ਰੱਖਦੇ ਹੋਏ ਗ਼ੈਰ-ਇੱਛਤ ਐਪਲੀਕੇਸ਼ਨ ਪਹੁੰਚ ਅਸਵੀਕਾਰ ਕਰੋ।