ਟਨਲ ਚੜ੍ਹਨ ਮਗਰੋਂ UFW VPN ਦਾ DNS ਸਰਵਰ ਛੱਡ ਦਿੰਦਾ ਹੈ
UFW ਦੀ ਡਿਫ਼ਾਲਟ ਇਨਕਾਰ ਨੀਤੀ ਟਨਲ ਦੇ ਇੰਟਰਫੇਸ ਨੂੰ ਵੀ ਢਕਦੀ ਹੈ। ਟ੍ਰੈਫ਼ਿਕ ਨੂੰ ਦਿਸ਼ਾ ਮੁਤਾਬਕ ਤਰਤੀਬ ਦਿਓ, tun0 ’ਤੇ ਧੱਕੇ ਹੋਏ resolver ਦੀ ਇਜਾਜ਼ਤ ਦਿਓ, ਫਿਰ ਬਾਹਰਲਾ ਰਾਹ ਖੋਲ੍ਹੋ।
VPN ਜੁੜਦਿਆਂ ਹੀ ਨਾਵਾਂ ਦਾ ਹੱਲ ਹੋਣਾ ਬੰਦ ਹੋ ਜਾਂਦਾ ਹੈ, ਜਦੋਂ ਕਿ ਜਨਤਕ ਪਤੇ ’ਤੇ ping ਹਾਲੇ ਵੀ ਜਵਾਬ ਦਿੰਦਾ ਹੈ ਅਤੇ ਫਾਇਰਵਾਲ ਸਥਿਤੀ ਵਿੱਚ ਗਲਤ ਦਿਸਣ ਵਾਲਾ ਕੁਝ ਨਹੀਂ ਦਿਸਦਾ। ਨੀਤੀ ਵਿੱਚ ਕੁਝ ਨਹੀਂ ਬਦਲਿਆ; ਬਦਲਿਆ ਇਹ ਹੈ ਕਿ ਨਵਾਂ ਇੰਟਰਫੇਸ ਆਇਆ, ਅਤੇ ਡਿਫ਼ਾਲਟ ਇਨਕਾਰ ਪਹਿਲੇ ਪੈਕੇਟ ਤੋਂ ਹੀ ਉਸ ਨੂੰ ਢਕ ਲੈਂਦਾ ਹੈ। UFW ਦਿਸ਼ਾ ਅਤੇ ਇੰਟਰਫੇਸ ਦੇ ਆਧਾਰ ’ਤੇ ਫ਼ੈਸਲਾ ਕਰਦਾ ਹੈ, ਇਸ ਲਈ ਵਾਇਰਲੈੱਸ ਲਿੰਕ ਲਈ ਲਿਖਿਆ ਨਿਯਮ ਟਨਲ ਵਿੱਚੋਂ ਬਾਹਰ ਜਾਣ ਵਾਲੇ ਟ੍ਰੈਫ਼ਿਕ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਕਹਿੰਦਾ। ਸੁਧਾਰ ਕੁਝ ਸੰਗੇ ਨਿਯਮ ਹਨ ਜੋ ਖ਼ਾਸ ਕ੍ਰਮ ਵਿੱਚ ਲਾਗੂ ਕੀਤੇ ਜਾਂਦੇ ਹਨ।
ਲੱਛਣ ਟਨਲ ਚੜ੍ਹਨ ਮਗਰੋਂ ਹੀ ਦਿਸਦਾ ਹੈ
ਡਿਫ਼ਾਲਟ ਇਨਕਾਰ ਨੀਤੀ ਉਹੀ ਕਰਦੀ ਹੈ ਜੋ ਉਸ ਨੂੰ ਕਿਹਾ ਗਿਆ: ਮਿਲਦਾ ਨਿਯਮ ਨਾ ਹੋਣ ਵਾਲ਼ਾ ਹਰ ਚੀਜ਼ ਇਨਕਾਰ ਹੁੰਦਾ ਹੈ, ਹਰ ਹੋਂਦ ਵਾਲੇ ਇੰਟਰਫੇਸ ’ਤੇ। ਨਿਯਮ ਲਿਖੇ ਜਾਣ ਵੇਲੇ ਟਨਲ ਨਹੀਂ ਸੀ, ਇਸ ਲਈ ਉਹਨਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਉਸ ਨੂੰ ਫੜ ਨਹੀਂ ਸਕਦਾ, ਅਤੇ ਜੋ ਇਨਕਾਰ ਹਮੇਸ਼ਾ ਸੀ ਉਹ ਹੁਣ ਨਾਵਾਂ ਦੇ ਹੱਲ ’ਤੇ ਲਾਗੂ ਹੁੰਦਾ ਹੈ। ਕਿਸੇ ਸ਼ਬਦੀ ਪਤੇ ’ਤੇ ਸਿੱਧਾ ਟ੍ਰੈਫ਼ਿਕ ਤਦ ਵੀ ਕੰਮ ਕਰ ਸਕਦਾ ਹੈ ਜਦੋਂ ਵੱਡੀ ਇਜਾਜ਼ਤ ਉਸ ਨੂੰ ਢਕਦੀ ਹੈ, ਅਤੇ ਇਸੇ ਲਈ ਜਨਤਕ resolver ’ਤੇ ping ਸਫਲ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਕਿ ਨਾਮ ਲੱਭਣਾ ਫੇਲ੍ਹ ਹੁੰਦਾ ਹੈ। ਘਾਟ ਉਸ ਇੰਟਰਫੇਸ ਲਈ ਨਿਯਮ ਹੈ ਜਿਸ ਨੂੰ ਨੀਤੀ ਨੇ ਕਦੇ ਨਹੀਂ ਵੇਖਿਆ।
ਇਹ ਵੀ ਦੱਸਦਾ ਹੈ ਕਿ ਨਾਕਾਮੀ ਸਾਫ਼ ਤੌਰ ’ਤੇ ਕਿਉਂ ਉਲਟਦੀ ਹੈ: ਟਨਲ ਹੇਠਾਂ ਲਾਹੋ ਅਤੇ ਨਾਵਾਂ ਦਾ ਹੱਲ ਫਿਰ ਹੁੰਦਾ ਹੈ, ਕਿਉਂਕਿ ਪੁੱਛਗਿੱਛ ਨਿਯਮਾਂ ਵਾਲੇ ਇੰਟਰਫੇਸ ’ਤੇ ਵਾਪਸ ਜਾਂਦੀ ਹੈ। ਸਿਰਫ਼ ਟਨਲ ਚੜ੍ਹਿਆ ਹੋਣ ਵੇਲੇ ਫੇਲ੍ਹ ਹੋਣ ਵਾਲੀ ਨੀਤੀ DNS ਸਮੱਸਿਆ ਨਹੀਂ ਹੈ, ਅਤੇ resolver ਨੂੰ ਹੀ ਟਿਊਨ ਕਰਨਾ ਇੱਥੇ ਸਭ ਤੋਂ ਵੱਧ ਸਮਾਂ ਬਰਬਾਦ ਕਰਦਾ ਹੈ। resolver ਸੰਰਚਨਾ ਪੜ੍ਹਨ ਤੋਂ ਪਹਿਲਾਂ ਇੰਟਰਫੇਸ ਸੂਚੀ ਪੜ੍ਹੋ।
ਤਿੰਨ ਦਿਸ਼ਾਵਾਂ, ਤਿੰਨ ਵੱਖਰੇ ਨਿਯਮ-ਸਮੂਹ
ਇੱਕ ਸੈਸ਼ਨ ਇੱਕ ਤੋਂ ਵੱਧ ਦਿਸ਼ਾਵਾਂ ਵਿੱਚ ਨਿਯਮਾਂ ਨੂੰ ਛੂਹਦਾ ਹੈ, ਅਤੇ ਟਨਲ ਲਗਭਗ ਹਰੇਕ ਵਿੱਚ ਦੂਜਾ ਇੰਟਰਫੇਸ ਜੋੜਦਾ ਹੈ। ਟ੍ਰੈਫ਼ਿਕ ਨੂੰ ਪਹਿਲਾਂ ਦਿਸ਼ਾ ਅਤੇ ਇੰਟਰਫੇਸ ਨਾਲ ਤਰਤੀਬ ਦੇਣਾ ਬਾਕੀ ਨੂੰ ਮਸ਼ੀਨੀ ਬਣਾ ਦਿੰਦਾ ਹੈ, ਕਿਉਂਕਿ ਹੇਠਾਂ ਦੀ ਹਰ ਕਤਾਰ ਨੂੰ ਆਪਣੀ ਥਾਂ ’ਤੇ ਆਪਣਾ ਨਿਯਮ ਚਾਹੀਦਾ ਹੈ। ਉਦਾਹਰਨਾਂ tun0 ਅਤੇ 10.8.0.0/24 ਦਾ ਤਾਲਾਬ ਵਰਤਦੀਆਂ ਹਨ, ਇਸ ਲਈ ਨਾਮ ਅਤੇ ਰੇਂਜਾਂ ਕਲਾਇੰਟ ਦੇ ਆਪਣੇ ਆਉਟਪੁੱਟ ਵਾਲੀਆਂ ਰੱਖੋ।
| Direction | Example packet | Rule that admits it | Written on |
|---|---|---|---|
| Client to the pushed resolver | A DNS query to 10.8.0.1 | Destination port 53 over the tunnel | The client's tun0 |
| Client to the VPN server | A handshake to the server's public address | Server address and port on the physical link | The client's physical interface |
| Server to a service | SSH from the pool to port 22 | Source pool, destination port, tunnel interface | The server's tun0 |
| Anyone to the listener | The VPN listener itself | 1194/udp on the public side | The server's public interface |
ਦੋ ਕਤਾਰਾਂ ਅਕਸਰ ਉਲਝ ਜਾਂਦੀਆਂ ਹਨ ਕਿਉਂਕਿ ਦੋਵੇਂ ਟਨਲ ਦਾ ਜ਼ਿਕਰ ਕਰਦੀਆਂ ਹਨ। resolver ਦਾ ਨਿਯਮ ਉਸ ਟ੍ਰੈਫ਼ਿਕ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ ਜੋ ਕਲਾਇੰਟ ਟਨਲ ਵਿੱਚ ਭੇਜਦਾ ਹੈ, ਜਦੋਂ ਕਿ SSH ਦਾ ਨਿਯਮ ਉਸ ਟ੍ਰੈਫ਼ਿਕ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ ਜੋ ਸਰਵਰ ਉੱਥੋਂ ਲੈਂਦਾ ਹੈ; ਉਹ ਵੱਖਰੀਆਂ ਮਸ਼ੀਨਾਂ ’ਤੇ ਰਹਿੰਦੇ ਹਨ ਅਤੇ ਸੁਤੰਤਰ ਤੌਰ ’ਤੇ ਫੇਲ੍ਹ ਹੁੰਦੇ ਹਨ। ਸਭ ਤੋਂ ਵੱਧ ਭੁੱਲੀ ਜਾਣ ਵਾਲੀ ਕਤਾਰ ਦੂਜੀ ਹੈ, ਕਿਉਂਕਿ ਸਰਵਰ ਦੇ ਜਨਤਕ ਪਤੇ ’ਤੇ ਕਲਾਇੰਟ ਦੇ ਟ੍ਰੈਫ਼ਿਕ ਦੀ ਇਜਾਜ਼ਤ ਮਿਲਣ ਤੱਕ ਕਲਾਇੰਟ ਟਨਲ ਬਣਾ ਹੀ ਨਹੀਂ ਸਕਦਾ। ਉੱਤੋਂ ਹੇਠਾਂ ਕੰਮ ਕਰੋ ਅਤੇ ਹਰ ਨਾਕਾਮੀ ਦਾ ਇੱਕ ਸੰਭਾਵੀ ਕਾਰਨ ਹੁੰਦਾ ਹੈ।
ਧੱਕੇ ਹੋਏ resolver ਨੂੰ ਆਪਣਾ ਨਿਯਮ ਚਾਹੀਦਾ ਹੈ
ਟਨਲ DNS ਢੋਂਦਾ ਹੈ ਜਾਂ ਨਹੀਂ, ਇਹ ਸਰਵਰ ਕੀ ਭੇਜਦਾ ਹੈ ’ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ। resolver ਵਿਕਲਪ ਧੱਕਣ ਵਾਲਾ ਸਰਵਰ ਕਲਾਇੰਟ ਦੀ ਸੰਰਚਨਾ ਵਿੱਚ ਨਿੱਜੀ ਪਤਾ ਲਾਉਂਦਾ ਹੈ, ਅਤੇ ਉਹ ਪਤਾ ਸਿਰਫ਼ ਟਨਲ ਰਾਹੀਂ ਹੀ ਰੂਟ ਹੋ ਸਕਦਾ ਹੈ। ਜੇ ਸਰਵਰ ਕੁਝ ਨਹੀਂ ਧੱਕਦਾ, ਤਾਂ ਕਲਾਇੰਟ ਪਹਿਲਾਂ ਵਾਲਾ resolver ਰੱਖਦਾ ਹੈ ਅਤੇ ਹੇਠਲੇ ਨਿਯਮਾਂ ਕੋਲ ਇਜਾਜ਼ਤ ਦੇਣ ਲਈ ਕੁਝ ਨਹੀਂ ਹੁੰਦਾ। ਕੁਝ ਲਿਖਣ ਤੋਂ ਪਹਿਲਾਂ ਧੱਕੀ ਹੋਈ ਸਥਿਤੀ ਅਤੇ ਮੌਜੂਦਾ ਪੁੱਛਗਿੱਛ ਨਤੀਜਾ ਜਾਂਚੋ:
dig +short @10.8.0.1 example.com
resolvectl status tun0
sudo ufw status numberedਸਥਿਤੀ ਆਉਟਪੁੱਟ ਵਰਤੇ ਜਾ ਰਹੇ resolver ਅਤੇ ਉਸ ਲਿੰਕ ਦਾ ਨਾਮ ਦੱਸਦੀ ਹੈ ਜਿਸ ਨਾਲ ਉਹ ਬੱਝਾ ਹੈ, ਅਤੇ ਉਸ ਪਿੱਛੇ ਦੀ ਰੂਟ ਖੋਜ ਦੱਸਦੀ ਹੈ ਕਿ ਕਿਹੜਾ ਇੰਟਰਫੇਸ ਉਸ ਪਤੇ ’ਤੇ ਪੁੱਛਗਿੱਛ ਢੋਵੇਗਾ। ਜਦੋਂ resolver ਕਿਸੇ ਹੋਰ ਲਿੰਕ ’ਤੇ ਬੈਠਾ ਹੋਵੇ, ਸਮੱਸਿਆ ਫਾਇਰਵਾਲ ਤੋਂ ਪਹਿਲਾਂ ਦੀ ਹੈ ਅਤੇ ਕੋਈ ਨਿਯਮ ਮਦਦ ਨਹੀਂ ਕਰੇਗਾ। ਜਦੋਂ ਦੋਵੇਂ ਟਨਲ ’ਤੇ ਸਹਿਮਤ ਹੋਣ, ਦੋ ਨਿਯਮ ਚਾਹੀਦੇ ਹਨ, ਕਿਉਂਕਿ ਬਹੁਤੀਆਂ ਪੁੱਛਗਿੱਛਾਂ UDP ਢੋਂਦਾ ਹੈ ਅਤੇ ਜਵਾਬ ਕੱਟਿਆ ਜਾਣ ’ਤੇ TCP ਸੰਭਾਲ ਲੈਂਦਾ ਹੈ। ਦੋਵੇਂ ਮੁੱਲ ਲਿਖੋ, ਕਿਉਂਕਿ ਨਿਯਮ ਇਹਨਾਂ ਦੇ ਹੀ ਨਾਮ ਲੈਣਗੇ:
sudo ufw allow out on tun0 to 10.8.0.1 port 53 proto udp comment 'pushed resolver'
sudo ufw allow out on tun0 to 10.8.0.1 port 53 proto tcp comment 'truncated answers'ਅੰਦਰਲੇ ਰਾਹ ਤੋਂ ਪਹਿਲਾਂ ਬਾਹਰਲਾ ਰਾਹ ਖੋਲ੍ਹੋ
ਟਨਲ ਬਣਨ ਤੋਂ ਪਹਿਲਾਂ ਕਲਾਇੰਟ ਨੂੰ ਸਰਵਰ ਦੇ ਜਨਤਕ ਪਤੇ ’ਤੇ ਪਹੁੰਚਣਾ ਪੈਂਦਾ ਹੈ, ਇਸ ਲਈ ਉਸ ਦਾ ਨਿਯਮ ਭੌਤਿਕ ਲਿੰਕ ’ਤੇ ਬੈਠਦਾ ਹੈ ਅਤੇ ਪਹਿਲਾਂ ਥਾਂ ’ਤੇ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਜੋ ਨੀਤੀ resolver ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦੀ ਹੈ ਪਰ ਸਰਵਰ ਭੁੱਲ ਜਾਂਦੀ ਹੈ, ਉਹ ਕਲਾਇੰਟ ਨੂੰ ਟਨਲ ਬਣਾਉਣ ਤੋਂ ਬਿਲਕੁਲ ਅਸਮਰੱਥ ਛੱਡ ਦਿੰਦੀ ਹੈ, ਅਤੇ ਇਹ ਲੱਛਣ ਆਮ ਤੌਰ ’ਤੇ kill switch ’ਤੇ ਸੁੱਟਿਆ ਜਾਂਦਾ ਹੈ। ਫਿਰ ਉਹਨਾਂ ਸੇਵਾਵਾਂ ਦੀ ਇਜਾਜ਼ਤ ਦਿਓ ਜੋ ਤੁਸੀਂ ਸੱਚਮੁੱਚ ਟਨਲ ਰਾਹੀਂ ਚਾਹੁੰਦੇ ਸੀ, ਇੱਕ ਵਾਰ ਵਿੱਚ ਇੱਕ ਸੰਗਾ ਨਿਯਮ, ਸਾਰਾ ਇੰਟਰਫੇਸ ਖੋਲ੍ਹਣ ਦੀ ਥਾਂ। ਸੰਗੇ ਨਿਯਮ ਹੀ ਉਹ ਕਾਰਨ ਹਨ ਜਿਸ ਕਰਕੇ ਇਨਕਾਰ ਆਪਣੀ ਥਾਂ ’ਤੇ ਰਹਿ ਸਕਦਾ ਹੈ।
sudo ufw allow out to 198.51.100.10 port 1194 proto udp comment 'vpn server'
sudo ufw allow out on tun0 to any port 443 proto tcp comment 'web through tunnel'ਜਾਂਚ ਵੇਲੇ ਕ੍ਰਮ ਮਹੱਤਵਪੂਰਨ ਹੈ, ਕਿਉਂਕਿ ਟਨਲ ਨੂੰ ਚੜ੍ਹਨ ਦੇਣ ਵਾਲਾ ਪਹਿਲਾ ਨਿਯਮ ਹੀ ਹੈ। ਉਹ ਜੋੜੋ, ਜੁੜੋ, ਅਤੇ ਸੇਵਾ-ਨਿਯਮ ਜੋੜਨ ਤੋਂ ਪਹਿਲਾਂ ਪੱਕਾ ਕਰੋ ਕਿ ਟਨਲ ਚੜ੍ਹਿਆ ਹੈ, ਕਿਉਂਕਿ ਦੋਵੇਂ ਇਕੱਠੇ ਕਰਨ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਨਾਕਾਮੀ ਇਹ ਨਹੀਂ ਦੱਸਦੀ ਕਿ ਕਿਹੜਾ ਅੱਧ ਗਲਤ ਹੈ। ਉੱਪਰਲੇ ਦਸਤਾਵੇਜ਼ੀ ਪਤੇ ਦੀ ਥਾਂ ਉਹ ਅੰਤ ਬਿੰਦੂ ਰੱਖੋ ਜਿਸ ਲਈ ਕਲਾਇੰਟ ਸੰਰਚਿਤ ਹੈ।
ਜਾਣ-ਬੁੱਝ ਕੇ ਡਿਸਕਨੈਕਟ ਕਰਕੇ ਕਲਾਇੰਟ ਪਾਸਾ ਪੂਰਾ ਕਰੋ। ਇਨਕਾਰ ਨੂੰ ਹਾਲੇ ਵੀ ਉਸ ਟ੍ਰੈਫ਼ਿਕ ਨੂੰ ਇਨਕਾਰ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ ਜੋ ਤੁਸੀਂ ਜਾਣ-ਬੁੱਝ ਕੇ ਬਾਹਰ ਰੱਖਿਆ, ਕਿਉਂਕਿ ਟਨਲ ਚੜ੍ਹਿਆ ਹੋਣ ਵੇਲੇ ਜਵਾਬ ਦੇਣ ਵਾਲਾ resolver ਸ਼ੱਕ ਹੋਣ ’ਤੇ ਇਨਕਾਰ ਕਰਨ ਵਾਲੀ ਨੀਤੀ ਦਾ ਸਿਰਫ਼ ਅੱਧਾ ਹਿੱਸਾ ਢਕਦਾ ਹੈ।
ਜੁੜਨ ਵਾਲਾ ਕਲਾਇੰਟ ਹਾਲੇ ਮਨਜ਼ੂਰ ਨਹੀਂ
ਸਰਵਰ ਨੂੰ ਵੀ ਆਪਣੀ ਦਿਸ਼ਾ ਸੋਚਣੀ ਪੈਂਦੀ ਹੈ, ਅਤੇ ਹੱਥ ਮਿਲਾਉਣ ਦੀ ਪ੍ਰਕਿਰਿਆ ਪੂਰੀ ਕਰਨ ਵਾਲਾ ਕਲਾਇੰਟ ਸਰਵਰ ਦੇ ਮਨਜ਼ੂਰ ਕਰਨ ਤੱਕ ਸਰਵਰ ’ਤੇ ਚੱਲਦੀ ਕਿਸੇ ਚੀਜ਼ ਤੱਕ ਨਹੀਂ ਪਹੁੰਚ ਸਕਦਾ। ਜਨਤਕ listener ਦਾ ਨਿਯਮ ਸਿਰਫ਼ ਟਨਲ ਦੀ ਹੋਂਦ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ; ਉਹ ਟਨਲ ਦੇ ਟ੍ਰੈਫ਼ਿਕ ਨੂੰ ਅੰਦਰ ਨਹੀਂ ਆਉਣ ਦਿੰਦਾ। ਸਰਵਰ ’ਤੇ ਇਹ ਦੋ ਨਿਯਮ ਅਤੇ ਇੱਕ ਜਾਂਚ ਹੈ ਕਿ ਸੇਵਾ ਸੱਚਮੁੱਚ ਸੁਣ ਰਹੀ ਹੈ:
sudo ufw allow 1194/udp comment 'openvpn listener'
sudo ufw limit in on tun0 from 10.8.0.0/24 to any port 22 proto tcp comment 'admin over tunnel'
ss -ltn | grep ':22'ਨਿਯਮ ਦਾ ਤਾਲਾਬ ਸਰਵਰ ਦੇ ਦਿੱਤੇ ਰੇਂਜ ਦੇ ਬਰਾਬਰ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਟਨਲ ਨੰਬਰ ਸਰਵਰ ਦੇ ਬਣਾਏ ਨਾਲ ਮਿਲਣਾ ਚਾਹੀਦਾ ਹੈ, ਕਿਉਂਕਿ ਹੋਰ ਇੰਟਰਫੇਸ ਲਈ ਨਿਯਮ ਨਿਯਮ ਨਾ ਹੋਣ ਤੋਂ ਵੱਖਰਾ ਨਹੀਂ ਪਛਾਣਿਆ ਜਾ ਸਕਦਾ। limit ਪ੍ਰਬੰਧਕੀ ਪੋਰਟ ਲਈ ਜਾਣ-ਬੁੱਝ ਕੇ ਹੈ, ਕਿਉਂਕਿ ਇਹ ਦੁਹਰਾਉਂਦੇ ਕਨੈਕਸ਼ਨਾਂ ਨੂੰ ਬਿਨਾਂ ਹੱਦ ਸਵੀਕਾਰ ਕਰਨ ਦੀ ਥਾਂ ਸੀਮਿਤ ਕਰਦਾ ਹੈ। listener ਜਾਂਚ ਬੰਦ ਪੋਰਟ ਅਤੇ ਸੁੱਟੇ ਗਏ ਪੈਕਟ ਨੂੰ ਵੱਖਰਾ ਕਰਦੀ ਹੈ, ਜੋ ਕਲਾਇੰਟ ਤੋਂ ਇੱਕੋ ਜਿਹੇ ਦਿਸਦੇ ਹਨ। ਨੰਬਰ ਵਾਲੇ ਨਿਯਮ ਵੀ ਪੂਰੀ ਤਸਵੀਰ ਨਹੀਂ: UFW ਦੇ before ਨਿਯਮ ਅਤੇ ਹੱਥ ਨਾਲ ਲਿਖੀ ਕੋਈ ਵੀ nftables ਲਾਈਨ ਪਹਿਲਾਂ ਮਿਲਦੀ ਹੈ ਅਤੇ ਸੂਚੀ ਜਿਸ ਪੈਕਟ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦੀ ਦਿਸਦੀ ਹੈ, ਉਸ ਨੂੰ ਵੀ ਹਾਲੇ ਇਨਕਾਰ ਕਰ ਸਕਦੀ ਹੈ।