UFW ਦੇ before.rules ਵਿੱਚ VPN NAT ਕਿੱਥੇ ਆਉਂਦਾ ਹੈ ਅਤੇ ਇਸਦੀ ਜਾਂਚ ਕਿਵੇਂ ਕਰੀਏ

ਸ਼ੈੱਲ ਵਿੱਚ ਟਾਈਪ ਕਰਨ ’ਤੇ ਕੰਮ ਕਰਨ ਵਾਲਾ NAT ਨਿਯਮ before.rules ਵਿੱਚ ਪੇਸਟ ਕਰਨ ’ਤੇ ਫੇਲ੍ਹ ਹੁੰਦਾ ਹੈ, ਕਿਉਂਕਿ ਉਹ ਫਾਈਲ ਸਕ੍ਰਿਪਟ ਨਹੀਂ ਹੈ। ਇਹ ਟੇਬਲ ਭਾਗਾਂ, ਚੇਨ ਘੋਸ਼ਣਾਵਾਂ ਅਤੇ ਹਰ ਟੇਬਲ ਲਈ COMMIT ਨਿਸ਼ਾਨ ਵਾਲਾ ਰੀਸਟੋਰ-ਫਾਰਮੈਟ ਦਸਤਾਵੇਜ਼ ਹੈ। ਗਲਤ ਥਾਂ ’ਤੇ ਲਾਈਨ ਜਾਂ ਤਾਂ ਪੂਰਾ ਰੀਸਟੋਰ ਰੋਕ ਦਿੰਦੀ ਹੈ ਜਾਂ ਤੁਹਾਡੇ ਮੰਨੇ ਹੋਏ ਨਿਯਮਾਂ ਨੂੰ ਚੁੱਪਚਾਪ ਕੱਢ ਦਿੰਦੀ ਹੈ। ਹੇਠਾਂ ਦਿੱਤਾ ਰਨਬੁੱਕ ਟੁਕੜੇ ਨੂੰ ਉੱਥੇ ਰੱਖਦਾ ਹੈ ਜਿੱਥੇ ਫਰੇਮਵਰਕ ਇਸਦੀ ਉਮੀਦ ਕਰਦਾ ਹੈ ਅਤੇ ਅਗਲੀ ਰੀਲੋਡ ਤੋਂ ਪਹਿਲਾਂ ਨਤੀਜਾ ਸਾਬਤ ਕਰਦਾ ਹੈ।

ਸ਼ੈੱਲ ਆਦੇਸ਼ ਰੀਸਟੋਰ ਫਾਈਲ ਨਹੀਂ ਹੈ

iptables -t nat ਨਾਲ ਸ਼ੁਰੂ ਹੋਣ ਵਾਲੀ ਲਾਈਨ iptables ਬਾਈਨਰੀ ਲਈ ਹਦਾਇਤ ਹੈ, ਜਦੋਂ ਕਿ UFW ਜੋ ਫਾਈਲ ਪੜ੍ਹਦਾ ਹੈ ਉਹ ਪੂਰੇ ਨਿਯਮ-ਸਮੂਹ ਦਾ ਵੇਰਵਾ ਹੈ। ਫ਼ਰਕ ਦਿਖਾਵਾ ਨਹੀਂ: ਰੀਸਟੋਰ ਫਾਰਮੈਟ ਨੂੰ ਪਤਾ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਇਹ ਕਿਸ ਟੇਬਲ ਵਿੱਚ ਹੈ, ਕਿਹੜੀਆਂ ਚੇਨਾਂ ਮੌਜੂਦ ਹਨ ਅਤੇ ਟੇਬਲ ਕਿੱਥੇ ਖ਼ਤਮ ਹੁੰਦਾ ਹੈ। ਉਸ ਦਸਤਾਵੇਜ਼ ਵਿੱਚ ਪੇਸਟ ਕੀਤਾ ਆਦੇਸ਼ ਜਾਂ ਤਾਂ ਸਿੰਟੈਕਸ ਗਲਤੀ ਹੈ ਜਾਂ, ਇਸ ਤੋਂ ਵੀ ਬੁਰਾ, ਗਲਤ ਟੇਬਲ ਨਾਲ ਜੁੜਿਆ ਨਿਯਮ। ਫਰੇਮਵਰਕ ਇਹ ਫਾਈਲਾਂ ਰੀਸਟੋਰ ਟੂਲਾਂ ਰਾਹੀਂ ਲੋਡ ਕਰਦਾ ਹੈ ਕਿਉਂਕਿ ਇਹ ਕ੍ਰਮਿਕ ਨਹੀਂ, ਘੋਸ਼ਣਾਤਮਕ ਹਨ।

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

ਟੁਕੜੇ ਨੂੰ ਮੌਜੂਦਾ ਟੇਬਲ ਭਾਗ ਦੇ ਅੰਦਰ ਰੱਖੋ

NAT ਟੁਕੜੇ ਦੀ ਇੱਕ ਸ਼ਕਲ ਹੁੰਦੀ ਹੈ, ਅਤੇ ਸ਼ਕਲ ਅੰਦਰਲੇ ਨਿਯਮ-ਪਾਠ ਨਾਲੋਂ ਵੱਧ ਜ਼ਰੂਰੀ ਹੈ। ਟੇਬਲ ਸਿਰਲੇਖ ਭਾਗ ਖੋਲ੍ਹਦਾ ਹੈ, ਚੇਨ ਘੋਸ਼ਣਾਵਾਂ ਕਾਊਂਟਰ ਸਥਾਪਿਤ ਕਰਦੀਆਂ ਹਨ, ਨਿਯਮ ਉਸ ਤੋਂ ਬਾਅਦ ਆਉਂਦੇ ਹਨ, ਅਤੇ COMMIT ਭਾਗ ਬੰਦ ਕਰਦਾ ਹੈ।

*nat
:POSTROUTING ACCEPT [0:0]
-A POSTROUTING -s 10.55.0.0/24 -o ens3 -j MASQUERADE
COMMIT

ਉੱਪਰਲਾ ਪੂਲ ਅਤੇ ਇੰਟਰਫੇਸ ਤੁਹਾਡੇ ਮੁੱਲਾਂ ਲਈ ਪਲੇਸਹੋਲਡਰ ਹਨ; ਕਾਪੀ ਕਰਨ ਯੋਗ ਭਾਗ ਬਣਤਰ ਹੈ। ਜੇ ਫਾਈਲ ਵਿੱਚ ਪਹਿਲਾਂ ਹੀ *nat ਭਾਗ ਹੈ, ਤਾਂ ਦੂਜਾ ਖੋਲ੍ਹਣ ਦੀ ਬਜਾਏ ਉਸੇ ਭਾਗ ਦੇ ਅੰਦਰ ਨਿਯਮ ਜੋੜੋ, ਕਿਉਂਕਿ ਫਾਰਮੈਟ ਹਰ ਟੇਬਲ ਲਈ ਇੱਕ COMMIT ਦੀ ਉਮੀਦ ਕਰਦਾ ਹੈ ਅਤੇ ਇੱਕੋ ਟੇਬਲ ਲਈ ਦੋ ਭਾਗ ਹੋਣਾ ਭਵਿੱਖ ਵਿੱਚ ਹੋਣ ਵਾਲੀ ਮੁਰੰਮਤ ਹੈ। ਵੰਡ ਦੀਆਂ ਚੇਨ ਪਰਿਭਾਸ਼ਾਵਾਂ ਨੂੰ ਅਛੂਤ ਰੱਖੋ, ਵਿਕਰੇਤਾ ਵੱਲੋਂ ਆਪਣੇ ਏਕੀਕਰਨ ਲਈ ਜੋੜੀਆਂ ਗਈਆਂ ਸਮੇਤ। UFW ਫਰੇਮਵਰਕ ਮੈਨੂਅਲ before, user ਅਤੇ after ਫਾਈਲਾਂ ਅਤੇ ਮੇਲ ਖਾਂਦੇ COMMIT ਦੀ ਲੋੜ ਦਾ ਦਸਤਾਵੇਜ਼ੀਕਰਨ ਕਰਦਾ ਹੈ।

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

ਉਮੀਦਵਾਰ ਨੂੰ ਲਾਗੂ ਕੀਤੇ ਬਿਨਾਂ ਜਾਂਚੋ

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

sudo cp /etc/ufw/before.rules /root/before.rules.bak
sudo iptables-restore --test < /root/before.rules.bak
echo "exit: 0"

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

ਸਥਾਪਿਤ ਬੈਕਐਂਡ ਅਤੇ ਪਤਾ ਪਰਿਵਾਰ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਟੂਲ ਚੁਣੋ। ਅਨੁਕੂਲਤਾ ਪਰਤ ਰਾਹੀਂ nft ਬੈਕਐਂਡ ਚਲਾਉਣ ਵਾਲੇ ਹੋਸਟ ਨੂੰ ਸੰਬੰਧਿਤ ਕਮਾਂਡ ਦੀ ਲੋੜ ਹੈ, ਅਤੇ IPv6 ਨਿਯਮ ਪੂਰੀ ਤਰ੍ਹਾਂ ਵੱਖਰੀ ਫਾਈਲ ਵਿੱਚ ਰਹਿੰਦੇ ਹਨ।

ਫਾਰਵਰਡਿੰਗ, NAT ਅਤੇ ਪਹੁੰਚ ਨੀਤੀ ਵੱਖਰੀ ਰੱਖੋ

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

sysctl net.ipv4.ip_forward
sudo iptables -t nat -S POSTROUTING
sudo iptables -S FORWARD

ਉਹ ਤਿੰਨ ਆਉਟਪੁੱਟ ਇਕੱਠੇ ਪੜ੍ਹੋ, ਇੱਕ-ਇੱਕ ਕਰਕੇ ਨਹੀਂ। ਫਾਰਵਰਡਿੰਗ ਬੰਦ ਵਾਲਾ masquerade ਨਿਯਮ ਅਜਿਹਾ ਕਲਾਇੰਟ ਬਣਾਉਂਦਾ ਹੈ ਜੋ ਜੁੜਦਾ ਹੈ ਪਰ ਕਿਤੇ ਨਹੀਂ ਪਹੁੰਚਦਾ, ਜੋ ਕਲਾਇੰਟ ਪਾਸਿਓਂ ਬਿਲਕੁਲ ਮਾਰਗ ਖਰਾਬੀ ਵਾਂਗ ਦਿਸਦਾ ਹੈ ਅਤੇ ਲੋਕਾਂ ਨੂੰ ਗਲਤ ਫਾਈਲ ਵੱਲ ਭੇਜਦਾ ਹੈ। ਫਿਲਟਰ ਟੇਬਲ ਉਹ ਥਾਂ ਵੀ ਹੈ ਜਿੱਥੇ ਬਹੁਤ ਚੌੜਾ accept ਲੁਕਿਆ ਰਹਿੰਦਾ ਹੈ, ਇਸ ਲਈ ਉੱਥੇ ਹੁੰਦਿਆਂ ਇਸਦੀ ਡਿਫਾਲਟ ਨੀਤੀ ਵੇਖੋ।

ਰੀਲੋਡ, ਰੱਦ ਅਤੇ VPN ਨੁਕਸਾਨ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ

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

sudo ufw reload
sudo ufw status verbose
sudo iptables -t nat -L POSTROUTING -n -v

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

IPv4 ਦਾ NAT IPv6 ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਕਹਿੰਦਾ, ਇਸ ਲਈ ਨਿਯਮ ਦੇ ਨਾਲ ਉਸੇ ਨੋਟ ਵਿੱਚ ਦੋਵਾਂ ਪਰਿਵਾਰਾਂ ਲਈ ਇਰਾਦਾ ਕਵਰੇਜ ਦੱਸੋ। ਟੀਚਾ ਸੁਸੰਗਤ ਪ੍ਰਬੰਧਿਤ ਨੀਤੀ ਹੈ, ਅਤੇ ਸੰਜੋਗ ਨਾਲ ਪਾਰਸ ਹੋਇਆ ਟੁਕੜਾ ਇਸਦਾ ਸਬੂਤ ਨਹੀਂ ਹੈ।