UFW ਨਿਯਮਾਂ ਨਾਲ OpenVPN ਗੇਟਵੇ ਨੂੰ ਇੱਕ LAN ਤੱਕ ਸੀਮਿਤ ਕਰੋ

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

ਪਹਿਲਾਂ ਟੋਪੋਲੋਜੀ ਅਤੇ ਇਜਾਜ਼ਤ ਲਿਖੋ

ਉਦਾਹਰਨ ਵਰਤਦੀ ਹੈ ਵਰਤੋਂਕਾਰ ਥਾਂ ਦੇ TUN ਯੰਤਰ ਨੂੰ ਕਿਹਾ ਜਾਂਦਾ ਹੈ ਵਾਲਾ Community OpenVPNtun0 ਸਰਵਰ, ਕਲਾਇੰਟ ਪੂਲ 10.77.0.0/24, ਅਤੇ ਇੱਕ ਜੁੜਿਆ ਸਬਨੈੱਟ 192.168.60.0/24 lan0 ਉੱਤੇ। IPv4 ਫਾਰਵਰਡਿੰਗ ਪਹਿਲਾਂ ਹੀ ਕੰਮ ਕਰਦੀ ਹੈ ਅਤੇ LAN ਕੋਲ ਪੂਲ ਵੱਲ ਵਾਪਸੀ ਰੂਟ ਪਹਿਲਾਂ ਹੀ ਹੈ, ਇਸ ਲਈ ਇੱਥੇ ਕੁਝ ਵੀ ਉਨ੍ਹਾਂ ਦਰਮਿਆਨ ਅਨੁਵਾਦ ਉੱਤੇ ਨਿਰਭਰ ਨਹੀਂ ਹੈ।

ਇਸ ਹੋਸਟ ਦਾ ਫਾਇਰਵਾਲ UFW ਦੀ ਮਲਕੀਅਤ ਹੈ, ਅਤੇ ਕੋਈ ਕੰਟੇਨਰ ਨਿਯਮ-ਸਮੂਹ ਜਾਂ ਵੱਖਰੀ nftables ਸਾਰਣੀ ਪਹਿਲਾਂ ਦਾ ਪ੍ਰਵਾਨਗੀ ਰਾਹ ਨਹੀਂ ਲਗਾ ਸਕਦੀ। ਫਿਲਟਰ ਛੱਡਣ ਵਾਲਾ ਫਲੋ-ਆਫਲੋਡ ਸ਼ਾਰਟਕੱਟ ਗਾਰਡ ਲੜੀਆਂ ਨੂੰ ਸਿਰਫ਼ ਸਜਾਵਟ ਬਣਾ ਦੇਵੇਗਾ, ਇਸ ਲਈ ਪੱਕਾ ਕਰੋ ਕਿ ਕੋਈ ਵੀ ਸਰਗਰਮ ਨਹੀਂ ਹੈ। OpenVPN ਦੀ ਆਪਣੀ client-to-client ਫਾਰਵਰਡਿੰਗ ਬੰਦ ਰੱਖੋ, ਕਿਉਂਕਿ ਉਹ ਸਾਥੀ-ਨਾਲ-ਸਾਥੀ ਟ੍ਰੈਫਿਕ ਜੋ ਕਦੇ ਵੀ ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ ਦਾ ਫਿਲਟਰ ਨਹੀਂ ਲੰਘਦਾ ਉਸ ਨਾਲ ਸੀਮਿਤ ਨਹੀਂ ਕੀਤਾ ਜਾ ਸਕਦਾ। ਬਾਹਰੀ ਸੁਣਨ ਵਾਲਾ ਅਤੇ ਪ੍ਰਬੰਧਕੀ ਨਿਯਮ ਜਿਵੇਂ ਹਨ ਤਿਵੇਂ ਰਹਿੰਦੇ ਹਨ, ਕਿਉਂਕਿ ਇਹ ਬਦਲਾਅ ਫਾਇਰਵਾਲ ਬਦਲਣ ਦੀ ਥਾਂ ਡੀਕ੍ਰਿਪਟ ਕੀਤੇ ਟਨਲ ਟ੍ਰੈਫਿਕ ਨੂੰ ਨਿਯੰਤਰਿਤ ਕਰਦਾ ਹੈ।

ਗਾਰਡਾਂ ਨੂੰ UFW ਦੀਆਂ ਸ਼ੁਰੂਆਤੀ ਪ੍ਰਵਾਨਗੀਆਂ ਤੋਂ ਪਹਿਲਾਂ ਰੱਖੋ

ਰੂਟ ਇਜਾਜ਼ਤ ਅਤੇ ਉਸ ਤੋਂ ਬਾਅਦ ਇਨਕਾਰ ਸਖ਼ਤ ਸੀਮਾ ਲਈ ਕਾਫ਼ੀ ਨਹੀਂ ਹੈ। ਸਟਾਕ before ਨਿਯਮ ਕਿਸੇ ਵੀ ਵਰਤੋਂਕਾਰ ਨਿਯਮ ਨੂੰ ਦੇਖਣ ਤੋਂ ਪਹਿਲਾਂ ਹੀ ਸਥਾਪਿਤ ਟ੍ਰੈਫਿਕ ਅਤੇ ਕੁਝ ICMP ਪ੍ਰਵਾਨ ਕਰਦੇ ਹਨ, ਇਸ ਲਈ ਪਿਛਲੇ ਹਫ਼ਤੇ ਮਨਜ਼ੂਰ ਹੋਇਆ ਫਲੋ ਨਵੀਂ ਮੰਜ਼ਿਲ ਸੀਮਾ ਤੋਂ ਬਾਹਰ ਰਹਿ ਸਕਦਾ ਹੈ, ਸਿਰਫ਼ ਇਸ ਲਈ ਕਿ ਉਸ ਦੀ ਹਾਲਤ ਅਜੇ ਹੈ। UFW ਫ਼ਾਈਲਾਂ ਦਾ ਬੈਕਅੱਪ ਲਓ ਅਤੇ ਸੋਧ ਤੋਂ ਪਹਿਲਾਂ ਆਊਟ-ਆਫ-ਬੈਂਡ ਕੰਸੋਲ ਖੁੱਲ੍ਹਾ ਰੱਖੋ।

ਫ਼ਾਈਲ ਦੇ *filter ਭਾਗ ਵਿੱਚ /etc/ufw/before.rules, ਮੌਜੂਦਾ ਐਲਾਨਾਂ ਦੇ ਕੋਲ ਅਤੇ ਕਿਸੇ ਵੀ ਨਿਯਮ ਲਾਈਨ ਤੋਂ ਪਹਿਲਾਂ ਦੋ ਲੜੀਆਂ ਐਲਾਨੋ।

:vpn-src-guard - [0:0]
:vpn-reply-guard - [0:0]

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

-A ufw-before-input -i tun0 -j DROP
-A ufw-before-forward -i tun0 -j vpn-src-guard
-A ufw-before-forward -o tun0 -j vpn-reply-guard

-A vpn-src-guard -o lan0 -d 192.168.60.0/24 -s 10.77.0.0/24 -m conntrack --ctdir ORIGINAL -j RETURN
-A vpn-src-guard -j DROP

-A vpn-reply-guard -i lan0 -d 10.77.0.0/24 -s 192.168.60.0/24 -m conntrack --ctstate RELATED,ESTABLISHED --ctdir REPLY -j RETURN
-A vpn-reply-guard -j DROP

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

ਹਰ ਗਾਰਡ ਕੀ ਲੰਘਣ ਦਿੰਦਾ ਹੈ ਅਤੇ ਕੀ ਇਨਕਾਰ ਕਰਦਾ ਹੈ ਪੜ੍ਹੋ

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

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

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

ਸਬਨੈੱਟ ਨੂੰ ਅਧਿਕਾਰ ਦਿਓ ਅਤੇ ਪਾਸਿਆਂ ਦੇ ਦਰਵਾਜ਼ੇ ਬੰਦ ਕਰੋ

ਪਹਿਲਾਂ ਰੂਟ ਇਜਾਜ਼ਤ ਦਾ ਪੂਰਵਦਰਸ਼ਨ ਕਰੋ, ਫਿਰ ਲਾਗੂ ਕਰਨ ਲਈ ਪੂਰਵਦਰਸ਼ਨ ਝੰਡਾ ਹਟਾਓ: sudo ufw --dry-run route allow in on tun0 out on lan0 from 10.77.0.0/24 to 192.168.60.0/24. ਉਸ ਤੋਂ ਬਾਅਦ ਵਰਤੋਂਕਾਰ ਨਿਯਮਾਂ ਦਾ ਕ੍ਰਮ ਵੇਖੋ, ਕਿਉਂਕਿ ਪਹਿਲਾਂ ਦਾ ਇਨਕਾਰ ਅਜੇ ਵੀ ਬਾਅਦ ਦੀ ਇਜਾਜ਼ਤ ਉੱਤੇ ਜਿੱਤਦਾ ਹੈ। ਪੂਰੇ ਸਬਨੈੱਟ ਦੀ ਇਜਾਜ਼ਤ ਵੀ ਗਲਤ ਸ਼ਕਲ ਹੈ ਜਦੋਂ ਸਿਰਫ਼ ਇੱਕ ਹੋਸਟ ਦਾ HTTPS ਪੋਰਟ ਪਹੁੰਚਯੋਗ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।

ਧਿਆਨ ਦਿਓ ਕਿ ਇਨਪੁਟ ਸੁੱਟਣਾ ਕੀ ਕਰਦਾ ਹੈ: ਟਨਲ ਕਲਾਇੰਟ ਗੇਟਵੇ ਉੱਤੇ ਹੀ ਕਿਸੇ ਵੀ ਸੇਵਾ ਤੱਕ ਨਹੀਂ ਪਹੁੰਚ ਸਕਦੇ, ਜਿਸ ਵਿੱਚ ਉਸ ਦੇ LAN ਪਤੇ ਨਾਲ ਬੱਝਿਆ DNS ਸੁਣਨ ਵਾਲਾ ਸ਼ਾਮਲ ਹੈ। ਉੱਥੇ DNS ਹੋਸਟ ਕਰਨ ਲਈ ਸੁੱਟਣ ਤੋਂ ਪਹਿਲਾਂ ਜਾਣ-ਬੁੱਝ ਕੇ ਕੀਤਾ ਅਪਵਾਦ ਅਤੇ ਸੋਧਿਆ ਇਜਾਜ਼ਤ ਇਕਰਾਰਨਾਮਾ ਲੋੜੀਂਦਾ ਹੈ। ਜੇ UFW IPv6 ਸੰਭਾਲਦਾ ਹੈ, ਤਾਂ tun0 ਲਈ before6.rules ਫ਼ਾਈਲ ਵਿੱਚ ਵੀ ਮਿਲਦੇ ਸੁੱਟਣ ਜੋੜੋ, ਕਿਉਂਕਿ IPv4 ਮੰਜ਼ਿਲਾਂ ਦੀ ਸੂਚੀ IPv6 ਪੈਕਟਾਂ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਕਹਿੰਦੀ।

ਪੂਰਵਦਰਸ਼ਨ ਨਹੀਂ, ਲੋਡ ਹੋਈ ਨੀਤੀ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ

ਮੁੜ-ਲੋਡ ਦਾ ਪੂਰਵਦਰਸ਼ਨ ਕਰੋ, ਸੰਭਾਲ ਵਿੰਡੋ ਵਿੱਚ ਲਾਗੂ ਕਰੋ, ਅਤੇ ਜੀਵੰਤ ਨਿਯਮ-ਸਮੂਹ ਪੜ੍ਹੋ।

sudo ufw --dry-run reload
sudo ufw show raw

ਪੱਕਾ ਕਰੋ ਕਿ ਟਨਲ ਗਾਰਡ ਡਿਫ਼ਾਲਟ ਹਾਲਤ ਅਤੇ ICMP ਇਜਾਜ਼ਤਾਂ ਤੋਂ ਪਹਿਲਾਂ ਦਿਖਦੇ ਹਨ। ਸਾਧਾਰਨ ufw status ਹੱਥ ਨਾਲ ਸੋਧੇ before ਨਿਯਮ ਨਹੀਂ ਦਿਖਾਉਂਦਾ, ਇਸ ਲਈ ਚਾਲਕ ਸਿੱਟਾ ਕੱਢਦੇ ਹਨ ਕਿ ਨਿਯਮ ਗਾਇਬ ਹੈ ਜਦੋਂ ਕਿ ਉਹ ਅਸਲ ਵਿੱਚ ਲੋਡ ਹੈ। ਟੁਕੜਾ ਲੱਭਣ ਦੀ ਥਾਂ ਕੱਚੀ ਸੂਚੀ ਉੱਤੋਂ ਹੇਠਾਂ ਪੜ੍ਹੋ। ਜੇ ਗਾਰਡ ਹਾਲਤ ਇਜਾਜ਼ਤ ਤੋਂ ਬਾਅਦ ਦਿਖਦੇ ਹਨ, ਤਾਂ ਸੀਮਾ ਉਹ ਨਹੀਂ ਕਰ ਰਹੀ ਜੋ ਫ਼ਾਈਲ ਕਹਿੰਦੀ ਹੈ।

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

ਨਿਯਮਾਂ ਦੇ ਨਾਲ ਸੀਮਾਵਾਂ ਦਰਜ ਕਰੋ: ਇਹ ਟ੍ਰਾਂਜ਼ਿਟ ਨੂੰ ਸੀਮਿਤ ਕਰਦਾ ਹੈ ਅਤੇ ਹੋਰ ਕੁਝ ਨਹੀਂ। ਇਹ ਕਲਾਇੰਟ ਨੂੰ ਆਪਣਾ ਇੰਟਰਨੈੱਟ ਕਨੈਕਸ਼ਨ ਵਰਤਣ ਤੋਂ ਨਹੀਂ ਰੋਕਦਾ, ਮਨਜ਼ੂਰ LAN ਹੋਸਟ ਨੂੰ ਟ੍ਰੈਫਿਕ ਅੱਗੇ ਭੇਜਣ ਤੋਂ ਨਹੀਂ ਰੋਕਦਾ, ਅਤੇ ਮਨਜ਼ੂਰ ਸੇਵਾਵਾਂ ਦੇ ਅੰਦਰਲੇ ਪ੍ਰਮਾਣੀਕਰਨ ਦੀ ਥਾਂ ਨਹੀਂ ਲੈਂਦਾ।