ਹਰ VPN ਕਲਾਇੰਟ ਪੂਲ ਲਈ ਇੱਕ ਮੰਜ਼ਿਲ ਰੇਂਜ ਬਲਾਕ ਕਰੋ
ਇੱਕ nftables ਨਿਯਮ ਗੇਟਵੇ ਦੇ ਆਪਣੇ ਟ੍ਰੈਫਿਕ ਨੂੰ ਛੂਹਣ ਤੋਂ ਬਿਨਾਂ ਮਨਜ਼ੂਰਸ਼ੁਦਾ VPN ਪੂਲ ਲਈ ਮੰਜ਼ਿਲ ਪ੍ਰੀਫਿਕਸ ਨੂੰ ਰੱਦ ਕਰ ਸਕਦਾ ਹੈ। ਹੁੱਕ ਅਤੇ ਸਥਿਤੀ ਮਿਲਾਓ।
ਇੱਕ ਨਿਯਮ ਮਨਜ਼ੂਰਸ਼ੁਦਾ VPN ਪੂਲ ਨੂੰ ਮੰਜ਼ਿਲ ਰੇਂਜ ਤੋਂ ਦੂਰ ਰੱਖ ਸਕਦਾ ਹੈ, ਗੇਟਵੇ ਦੇ ਹੋਰ ਕੰਮ ਵਿੱਚ ਰੁਕਾਵਟ ਪਾਏ ਬਿਨਾਂ। ਨਿਯਮ ਆਪਣੇ ਆਪ ਵਿੱਚ ਛੋਟਾ ਹੈ; ਇਹ ਕੰਮ ਕਰੇਗਾ ਜਾਂ ਨਹੀਂ, ਇਹ ਤੈਅ ਕਰਨ ਵਾਲੇ ਹਿੱਸੇ ਹਨ ਜਿਸ ਹੁੱਕ ਵਿੱਚ ਇਹ ਰਹਿੰਦਾ ਹੈ ਅਤੇ ਚੇਨ ਵਿੱਚ ਇਸਦੀ ਸਥਿਤੀ। ਇਹਨਾਂ ਦੋਹਾਂ ਵਿੱਚ ਗਲਤੀ ਕਰੋ ਤਾਂ ਸਹੀ ਦਿਸਣ ਵਾਲਾ ਪਰ ਅਸੰਗਤ ਵਿਵਹਾਰ ਕਰਨ ਵਾਲਾ ਫਾਇਰਵਾਲ ਮਿਲਦਾ ਹੈ। ਨਿਯਮ ਪੈਕੇਟ ਨੂੰ ਵੇਖਦਾ ਹੈ ਤਦ ਪੈਕੇਟ ਕੀ ਕਰ ਰਿਹਾ ਹੈ, ਉੱਥੋਂ ਸ਼ੁਰੂ ਕਰੋ।
ਨਿਯਮ ਅਸਲ ਵਿੱਚ ਕੀ ਮਿਲਾਉਂਦਾ ਹੈ
ਨਿਯਮ ਇੱਕੋ ਸਮੇਂ ਤਿੰਨ ਚੀਜ਼ਾਂ ਮਿਲਾਉਂਦਾ ਹੈ: ਇਨਪੁਟ ਇੰਟਰਫੇਸ, ਸਰੋਤ ਪ੍ਰੀਫਿਕਸ ਅਤੇ ਮੰਜ਼ਿਲ ਪ੍ਰੀਫਿਕਸ। ਡ੍ਰਾਪ ਲਾਗੂ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਤਿੰਨੇ ਸੱਚੇ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ, ਅਤੇ ਇਹੀ ਇਸਨੂੰ ਤੰਗ ਰੱਖਦਾ ਹੈ। ਇਸਨੂੰ ਤਿੰਨ ਵੱਖਰੀਆਂ ਨੀਤੀਆਂ ਵਜੋਂ ਪੜ੍ਹਨ ਨਾਲੋਂ ਇੱਕ ਸਮੀਕਰਨ ਵਜੋਂ ਪੜ੍ਹਨਾ ਸੌਖਾ ਹੈ।
ਇੰਟਰਫੇਸ ਮਿਲਾਣ ਹੀ ਫਾਰਵਰਡ ਕੀਤੇ ਕਲਾਇੰਟ ਟ੍ਰੈਫਿਕ ਨੂੰ ਗੇਟਵੇ ਦੇ ਆਪਣੇ ਕਨੈਕਸ਼ਨਾਂ ਤੋਂ ਵੱਖ ਕਰਦਾ ਹੈ। ਇਸ ਤੋਂ ਬਿਨਾਂ, ਸਿਰਫ਼ ਸਰੋਤ ਪੂਲ ਦਾ ਨਾਮ ਲੈਣ ਵਾਲਾ ਨਿਯਮ ਗੇਟਵੇ ਵੱਲੋਂ ਉਸ ਪਤੇ ਤੋਂ ਬਣਾਏ ਪੈਕੇਟਾਂ ਨੂੰ ਵੀ ਪ੍ਰਭਾਵਿਤ ਕਰੇਗਾ, ਜੇ ਕਦੇ ਇਹ ਹੁੰਦਾ ਹੈ। ਸਰੋਤ ਪ੍ਰੀਫਿਕਸ ਨੀਤੀ ਨੂੰ ਮਨਜ਼ੂਰ ਕਲਾਇੰਟਾਂ ਤੱਕ ਸੀਮਤ ਕਰਦਾ ਹੈ, ਅਤੇ ਮੰਜ਼ਿਲ ਪ੍ਰੀਫਿਕਸ ਇਸਨੂੰ ਇੱਕ ਰੇਂਜ ਤੱਕ। ਨਿਯਮ ਨੂੰ ਸੂਚੀ ਨਹੀਂ, ਕਟਾਅ ਵਜੋਂ ਪੜ੍ਹੋ।
ਕੁਝ ਵੀ ਸੋਧਣ ਤੋਂ ਪਹਿਲਾਂ ਤਿੰਨ ਮੁੱਲ ਲਿਖੋ: ਟਨਲ ਇੰਟਰਫੇਸ ਦਾ ਨਾਮ, ਸਰਵਰ ਵੱਲੋਂ ਵੰਡਿਆ ਪੂਲ, ਅਤੇ ਜਿਸ ਪ੍ਰੀਫਿਕਸ ਨੂੰ ਤੁਸੀਂ ਰੱਦ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ। ਇਹਨਾਂ ਵਿੱਚੋਂ ਕਿਸੇ ਵਿੱਚ ਵੀ ਟਾਈਪੋ ਹੋਵੇ ਤਾਂ ਸਾਫ਼ ਪਾਰਸ ਹੋਣ ਵਾਲਾ ਪਰ ਕੁਝ ਵੀ ਸੁਰੱਖਿਅਤ ਨਾ ਕਰਨ ਵਾਲਾ ਨਿਯਮ ਬਣਦਾ ਹੈ। ਉਹ ਤਿੰਨ ਮੁੱਲ ਨਿਯਮ ਦੇ ਕੋਲ ਬਦਲਾਅ ਰਿਕਾਰਡ ਵਿੱਚ ਰੱਖੋ।
ਹੁੱਕ ਤੈਅ ਕਰਦਾ ਹੈ ਕਿ ਨਿਯਮ ਕਿਸ 'ਤੇ ਲਾਗੂ ਹੁੰਦਾ ਹੈ
netfilter ਚੇਨ ਇੱਕ ਹੁੱਕ ਨਾਲ ਜੁੜੀ ਹੁੰਦੀ ਹੈ, ਅਤੇ ਕਿਹੜੇ ਪੈਕੇਟ ਚੇਨ ਵੇਖਦੀ ਹੈ, ਇਹ ਹੁੱਕ ਤੈਅ ਕਰਦਾ ਹੈ। forward ਹੁੱਕ ਗੇਟਵੇ ਰਾਹੀਂ ਰੂਟ ਹੋਣ ਵਾਲਾ ਟ੍ਰੈਫਿਕ ਵੇਖਦਾ ਹੈ, ਅਤੇ ਕਲਾਇੰਟ ਤੋਂ ਮੰਜ਼ਿਲ ਤੱਕ ਦਾ ਟ੍ਰੈਫਿਕ ਬਿਲਕੁਲ ਇਹੀ ਹੈ। ਚੇਨ ਵਿੱਚ ਬਾਕੀ ਸਭ ਕਿਸੇ ਹੋਰ ਦਰਸ਼ਕ ਵੱਲ ਹੈ।
input ਹੁੱਕ ਗੇਟਵੇ ਨੂੰ ਹੀ ਸੰਬੋਧਿਤ ਟ੍ਰੈਫਿਕ ਵੇਖਦਾ ਹੈ, ਇਸ ਲਈ ਉੱਥੇ ਰੱਖਿਆ ਨਿਯਮ ਟ੍ਰਾਂਜ਼ਿਟ ਨਹੀਂ, ਸਗੋਂ ਉਸਦੀਆਂ ਆਪਣੀਆਂ ਸੇਵਾਵਾਂ ਤੱਕ ਪਹੁੰਚ ਨਿਯੰਤਰਿਤ ਕਰਦਾ ਹੈ। output ਹੁੱਕ ਗੇਟਵੇ ਵੱਲੋਂ ਪੈਦਾ ਕੀਤਾ ਟ੍ਰੈਫਿਕ ਵੇਖਦਾ ਹੈ, ਜੋ ਕਲਾਇੰਟ ਪੂਲ ਨੀਤੀ ਦੀ ਲੋੜ ਦੇ ਉਲਟ ਹੈ। ਚੇਨ ਦੇ ਨਾਮ ਨਿਯਮ-ਸਮੂਹ ਲਿਖਣ ਵਾਲੇ ਵੱਲੋਂ ਚੁਣੇ ਗਏ ਮਨਮਾਨੇ ਲੇਬਲ ਹਨ, ਇਸ ਲਈ ਨਾਮ ਤੋਂ ਹੁੱਕ ਦਾ ਅੰਦਾਜ਼ਾ ਨਾ ਲਗਾਓ। ਚੇਨ ਕਿੱਥੇ ਜੁੜੀ ਹੈ ਜਾਂਚੋ, ਫਿਰ ਅੰਦਾਜ਼ਾ ਲਗਾਓ ਕਿ ਇਹ ਕੀ ਮਿਲਾ ਸਕਦੀ ਹੈ।
| Hook | Traffic it sees | Right for this policy |
|---|---|---|
| input | Addressed to the gateway | No, that is the host's own services |
| forward | Routed through the gateway | Yes, for client-to-destination traffic |
| output | Generated by the gateway | No, that is the opposite direction |
ਜੁੜਾਅ ਪੜ੍ਹਨਾ ਇੱਕ ਲਾਈਨ ਦੀ ਜਾਂਚ ਹੈ ਜੋ ਨਿਯਮ ਨੂੰ ਉਸ ਚੇਨ ਵਿੱਚ ਪੈਣ ਤੋਂ ਰੋਕਦੀ ਹੈ ਜੋ ਪੈਕੇਟ ਕਦੇ ਨਹੀਂ ਵੇਖਦੀ।
ਵਿਆਪਕ accept ਤੋਂ ਪਹਿਲਾਂ ਨਿਯਮ ਰੱਖੋ
ਨਿਯਮ ਕ੍ਰਮ ਵਿੱਚ ਮੁੱਲਾਂਕਣ ਹੁੰਦੇ ਹਨ, ਅਤੇ ਪਹਿਲਾ ਫੈਸਲਾ ਜਿੱਤਦਾ ਹੈ। ਚੇਨ ਵਿੱਚ ਪਹਿਲਾਂ ਵਾਲਾ ਵਿਆਪਕ accept ਜਿਨ੍ਹਾਂ ਪੈਕੇਟਾਂ ਨਾਲ ਮਿਲਦਾ ਹੈ ਉਨ੍ਹਾਂ ਲਈ ਮੁੱਲਾਂਕਣ ਖਤਮ ਕਰ ਦਿੰਦਾ ਹੈ, ਇਸ ਲਈ ਬਾਅਦ ਵਿੱਚ ਜੋੜਿਆ ਡ੍ਰਾਪ ਉਨ੍ਹਾਂ ਲਈ ਕਦੇ ਨਹੀਂ ਚੱਲਦਾ। ਇਹੀ ਕ੍ਰਮ-ਨਿਯਮ ਸਹੀ ਦਿਸਣ ਵਾਲੇ ਨਿਯਮ ਦਾ ਕੋਈ ਅਸਰ ਨਾ ਹੋਣ ਦਾ ਪੂਰਾ ਕਾਰਨ ਹੈ।
ਨਿਯਮ ਨੂੰ ਅੰਤ ਵਿੱਚ ਜੋੜਨ ਦੀ ਥਾਂ accept ਤੋਂ ਪਹਿਲਾਂ ਪਾਓ। ਜੇ ਚੇਨ ਵਿੱਚ ਟਨਲ ਇੰਟਰਫੇਸ ਲਈ ਪਹਿਲਾਂ ਹੀ ਆਮ accept ਹੈ, ਤਾਂ ਨਵਾਂ ਨਿਯਮ ਉਸਤੋਂ ਪਹਿਲਾਂ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਨਹੀਂ ਤਾਂ ਉਹ ਸਿਰਫ਼ ਸਜਾਵਟ ਹੈ। ਤੁਸੀਂ ਸੋਧੀ ਫਾਈਲ ਨਹੀਂ, ਨਤੀਜਾ ਕ੍ਰਮ ਜਾਂਚੋ, ਕਿਉਂਕਿ ਕਈ ਫਾਈਲਾਂ ਤੋਂ ਜੋੜਿਆ ਨਿਯਮ-ਸਮੂਹ ਕਿਸੇ ਇੱਕ ਨਾਲ ਵੀ ਨਹੀਂ ਮਿਲ ਸਕਦਾ। ਫਿਰ ਪੂਲ ਤੋਂ ਆਏ ਟੈਸਟ ਪੈਕੇਟ ਨਾਲ ਪੁਸ਼ਟੀ ਕਰੋ।
sudo nft list chain inet filter forward
sudo nft insert rule inet filter forward iifname "tun0" ip saddr 10.90.0.0/24 ip daddr 198.51.100.0/24 drop
sudo nft -c -f /etc/nftables.conf
ਤੀਜਾ ਕਮਾਂਡ ਫਾਈਲ ਨੂੰ ਲਾਗੂ ਕੀਤੇ ਬਿਨਾਂ ਪਾਰਸ ਕਰਦਾ ਹੈ, ਜੋ ਸਿੰਟੈਕਸ ਗਲਤੀਆਂ ਨੂੰ ਰੁਕਾਵਟ ਬਣਨ ਤੋਂ ਪਹਿਲਾਂ ਫੜਦਾ ਹੈ। ਰੋਲਬੈਕ ਯੋਜਨਾ ਨਾਲ ਲਾਗੂ ਕਰੋ, ਕਿਉਂਕਿ forward ਚੇਨ ਵਿੱਚ ਗਲਤ ਨਿਯਮ ਤੁਹਾਡੇ ਕੰਮ ਵਾਲੇ ਟਨਲ ਨੂੰ ਕੱਟ ਸਕਦਾ ਹੈ।
ਮੌਜੂਦਾ ਫਲੋ ਤੁਹਾਡੇ ਨਵੇਂ ਨਿਯਮ ਦੀ ਪਰਵਾਹ ਨਹੀਂ ਕਰਦੇ
ਨਿਯਮ ਦੇ ਹੋਂਦ ਵਿੱਚ ਆਉਣ ਤੋਂ ਪਹਿਲਾਂ ਬਣੀ conntrack ਐਂਟਰੀ ਪਹਿਲੇ accept ਨਾਲ ਮਿਲਦੀ ਰਹਿੰਦੀ ਹੈ। ਇਸੇ ਲਈ ਨਵਾਂ ਡ੍ਰਾਪ ਕਦੇ ਨਵੇਂ ਕਨੈਕਸ਼ਨਾਂ ਲਈ ਕੰਮ ਕਰਦਾ ਦਿਸਦਾ ਹੈ ਅਤੇ ਜਿਸਦੀ ਜਾਂਚ ਹੋ ਰਹੀ ਹੈ ਉਸ ਲਈ ਕੁਝ ਨਹੀਂ ਕਰਦਾ।
ਚੇਨ ਦੇ ਸਿਖਰ 'ਤੇ ਸਥਿਤੀ ਮਿਲਾਣ ਪੜ੍ਹੋ। ਜੇ ਇਹ ਤੁਹਾਡੇ ਨਿਯਮ ਤੋਂ ਪਹਿਲਾਂ established ਅਤੇ related ਟ੍ਰੈਫਿਕ ਸਵੀਕਾਰ ਕਰਦਾ ਹੈ, ਤਾਂ ਪਹਿਲਾਂ ਤੋਂ ਚੱਲ ਰਿਹਾ ਹਰ ਫਲੋ ਬੰਦ ਹੋਣ ਤੱਕ ਵਹਿੰਦਾ ਰਹਿੰਦਾ ਹੈ। ਐਮਰਜੈਂਸੀ ਨਿਯਮ ਲਈ ਆਮ ਤੌਰ 'ਤੇ ਇਹੀ ਵਿਵਹਾਰ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਤੁਰੰਤ ਕਟੌਤੀ ਦੀ ਉਮੀਦ ਕਰਨ 'ਤੇ ਇਹ ਉਲਝਣ ਪੈਦਾ ਕਰਦਾ ਹੈ। ਤੈਨਾਤ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਤੈਅ ਕਰੋ ਕਿ ਕਿਹੜਾ ਪ੍ਰਭਾਵ ਚਾਹੀਦਾ ਹੈ। ਖੁੱਲ੍ਹੇ ਕਨੈਕਸ਼ਨ ਦੀ ਮੁੜ ਵਰਤੋਂ ਕਰਨ ਵਾਲਾ ਟੈਸਟ ਤੁਹਾਨੂੰ ਗਲਤ ਕਹਾਣੀ ਸੁਣਾਏਗਾ।
sudo conntrack -L -s 10.90.0.14 -d 198.51.100.20
sudo nft list ruleset | grep -n -A3 'ct state'
ਪਹਿਲਾ ਕਮਾਂਡ ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਫਲੋ ਹੈ ਜਾਂ ਨਹੀਂ, ਅਤੇ ਦੂਜਾ ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਪਹਿਲਾਂ ਵਾਲਾ ਸਥਿਤੀ ਨਿਯਮ ਇਸਨੂੰ ਸਵੀਕਾਰ ਕਰਦਾ ਰਹਿੰਦਾ ਹੈ ਜਾਂ ਨਹੀਂ। ਦੋਵੇਂ ਸਿਰਫ਼-ਪੜ੍ਹਨ ਯੋਗ ਹਨ ਅਤੇ ਘਟਨਾ ਦੌਰਾਨ ਚਲਾਉਣਾ ਸੁਰੱਖਿਅਤ ਹੈ।
ਇਹ ਨਿਯਮ ਕੀ ਨਹੀਂ ਹੈ
ਨਿਯਮ ਡੋਮੇਨ ਕਾਲੀ ਸੂਚੀ, IPv6 ਨੀਤੀ ਜਾਂ ਕਿਸੇ ਇੱਕ ਐਪਲੀਕੇਸ਼ਨ ਖਾਤੇ 'ਤੇ ਪਾਬੰਦੀ ਨਹੀਂ ਹੈ।
ਇਹਨਾਂ ਵਿੱਚੋਂ ਹਰ ਇੱਕ ਨੂੰ ਆਪਣੀ ਵਿਧੀ ਚਾਹੀਦੀ ਹੈ। ਡੋਮੇਨ ਬਲਾਕ ਨੂੰ ਨਾਮ ਹੱਲ ਕਰਨੇ ਪੈਂਦੇ ਹਨ, ਜੋ ਪੈਕੇਟ ਫਿਲਟਰ ਨਹੀਂ ਕਰਦਾ। IPv6 ਟ੍ਰੈਫਿਕ ਨੂੰ ਆਪਣਾ ਮਿਲਾਣ ਚਾਹੀਦਾ ਹੈ, ਕਿਉਂਕਿ ip ਸਮੀਕਰਨ ip6 ਪੈਕੇਟਾਂ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਕਹਿੰਦਾ। ਐਪਲੀਕੇਸ਼ਨ-ਪੱਧਰੀ ਪਾਬੰਦੀ ਪ੍ਰੀਫਿਕਸ ਮਿਲਾਣ ਦੀ ਨਹੀਂ, ਸੇਵਾ ਜਾਂ ਪ੍ਰਮਾਣਿਤ ਪ੍ਰੌਕਸੀ ਦੀ ਹੁੰਦੀ ਹੈ। ਇਹਨਾਂ ਲੋੜਾਂ ਨੂੰ ਵੱਖਰਾ ਰੱਖਣਾ ਹੀ ਇੱਕ ਤੰਗ ਨਿਯਮ ਤੋਂ ਚਾਰ ਕੰਮ ਮੰਗਣ ਤੋਂ ਰੋਕਦਾ ਹੈ।
ਇਹ ਨਿਯਮ ਜੋ ਸਮਝੌਤਾ ਦਿੰਦਾ ਹੈ ਉਹ ਸਟੀਕ ਹੈ: ਮਨਜ਼ੂਰ ਪੂਲ ਤੋਂ ਇੱਕ ਮੰਜ਼ਿਲ ਪ੍ਰੀਫਿਕਸ ਵੱਲ ਟ੍ਰੈਫਿਕ ਰੱਦ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਜਦੋਂ ਕਿ ਅਸੰਬੰਧਿਤ ਗੇਟਵੇ ਟ੍ਰੈਫਿਕ ਆਪਣੀ ਮੌਜੂਦਾ ਨੀਤੀ ਰੱਖਦਾ ਹੈ। ਉਹ ਵਾਕ ਨਿਯਮ ਦੇ ਕੋਲ ਲਿਖੋ, ਅਤੇ ਅਗਲਾ ਵਿਅਕਤੀ ਜਾਣ ਜਾਵੇਗਾ ਕਿ ਇਹ ਕਿਸ ਲਈ ਸੀ।